From OpenStreetMap Wiki
Jump to navigation Jump to search
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. For adding extensions, once discussed and consensus is present, a wiki admin should be requested to add the suggestion as an issue to Add Structured Discussions (Flow) Wiki Extension.

Older requests can be found in archives, see yellow box below this line, on the right side of the page.

Much older requests can be found in an archived GitHub repository: openstreetmap/trac-tickets.

Visual editor isn't usable because of {{Fa}} template

Stuck: The actual request was solved but there is no solution for yet. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 12:01, 3 April 2022 (UTC)

By putting the {{fa}} template at beginning of Farsi pages, content of the page will be wrapped into it, and so, Visual editor doesn't allow direct editing, but we should edit the content via an interface like text editor.

I found out if I put direct HTML of the template instead of the template itself, visual editor will work.

An example page that uses the {{fa}} to make the page RTL, and the same page that uses the following HTML directly (HTML code from template):

<div lang="fa" dir="rtl" class="mw-content-rtl" style="direction:rtl;text-align:initial;font-family:'Noto Naskh Arabic',Noto,'Segoe UI','Iranian Sans',Tahoma,sans-serif;font-size:initial;line-height:1.6">

My question: is there any solution to avoid using this long piece of HTML code and at the same time visual editor work properly? iriman (talk) 13:15, 22 May 2019 (UTC)

What formatting and templates (if any) do multilingual WMF wikis such as Wikimedia Commons, and use? Does the Visual editor work there? --Andrew (talk) 19:09, 22 May 2019 (UTC)
seems they don't have visual editor as we have here. It's a translate functionality. but on commons there is some templates, for example main page in persian wikimedia commons has a template that uses langcode parameter, however I couldn't find visual editor. iriman (talk) 13:37, 23 May 2019 (UTC)

I tried out a workaround so that for using it without a parameter we should use <div {{fa}}> instead of bare {{fa}}. Apparently it works. Please take a look at my draft. iriman (talk) 14:22, 23 May 2019 (UTC)

I want to modify {{Fa}} as its sandbox version. Then change all instances of {{fa}} to <div {{fa}}> on all pages of this wiki (~300 pages) with a comment for users who are following those pages.
This will not hurt inline ones {{fa|some text}}, as you can see in my draft mentioned on previous message.
I cannot do this task manually, and willing someone do it automatically.
After that we also need to update {{Ltr}} (~50 pages). iriman (talk) 14:51, 24 May 2019 (UTC)
Regarding your question: WM Commons seems to use the page content language property. According to the MediaWiki documentation, changing the page language wraps the content area in <div lang="xyz" dir="ltr/rtl" class="mw-content-ltr/rtl">page content</div>. So, in this case it would be <div lang="fa" dir="rtl" class="mw-content-rtl">.... This solution looks a bit more professional for me, but it would not necessarily include the additional style definitions by {{Fa}}. Is that an issue? (from a technical POV, we would need to request the system administrators to carry out some configuration changes and it may take a few days to review.) --Tigerfell This user is member of the wiki team of OSM (Let's talk) 18:08, 24 May 2019 (UTC)
There is no Special:PageLanguage here though. --Andrew (talk) 08:44, 25 May 2019 (UTC)
That is what I meant with "configuration changes". First of all, they would need to enable setting languages for individual pages using $wgPageLanguageUseDB and then they need to assign the pagelang permission to some user group. I'd suggest either user or autoconfirmed (most of us are a member of both groups). The special page will then appear. The procedure for changing the page language would then work similar to changing the page content model using Special:ChangeContentModel. BTW, we could save the rest of the markup of {{Fa}} in MediaWiki:Common.css. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:57, 25 May 2019 (UTC)
@Tigerfell Definitely your solution is more professional. Font of the page and line height are important but not as important as page direction. With your solution if we'll have visual editor, I think we would be comfortable with it. iriman (talk) 11:24, 25 May 2019 (UTC)

@Iriman: The feature was added in openstreetmap/chef/pull/239. I already tried it out in my sandbox. Regarding the rest of the formatting, I would suggest you make an edit request at MediaWiki talk:Common.css for all RTL languages' formatting. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 20:52, 4 June 2019 (UTC)

Nice! Many thanks for following up on this issue. Ok, I will make a request there, thanks for the link! iriman (talk) 23:39, 4 June 2019 (UTC)
@Yurik: Is it possible to set this for all pages with language prefixes in their names by bot? --Andrew (talk) 06:21, 5 June 2019 (UTC)
Yes, it would be a fairly simple bot that would call action=setpagelanguage, but I am not sure how the bot will know the current language of the page - I couldn't find the api for that. Perhaps the bot will just keep a list of pages it has already modified. --Yurik (talk) 18:46, 5 June 2019 (UTC)
All pages except for those changed recently (after the configuration change) are in English (default language for this wiki). --Tigerfell This user is member of the wiki team of OSM (Let's talk) 20:10, 5 June 2019 (UTC)
+1. Also we need to remove {{Fa}}, {{Ar}}, etc. from beginning of those pages. But note that there may be some of these templates currently explicitly transcluded in block mode {{fa}}...</div> or inline mode {{fa|...}}. They should remain as they are now. iriman (talk) 19:01, 5 June 2019 (UTC)
Actually currently we may have {{fa}}...</div> or inline mode {{fa|...}} in other namespaces that are ltr. not an issue here. iriman (talk) 08:16, 6 June 2019 (UTC)
Long term maintenance could be done various ways, for instance putting a warning message and tracking category in the language template if the language set in Mediawiki differs from the one inferred from the page name. Populating the language tags in the first place is the tedious bit. --Andrew (talk) 07:36, 6 June 2019 (UTC)
Why do we need to have the correct language setting for all pages? It would be obviously nice to know and a good info for search engines and the like, but apart from that? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 17:23, 6 June 2019 (UTC)
It could be useful for language-specific formatting, for example font face (since it's a common need between all languages). This is a possibility only. Users of a language may need it, or not if default configuratuon satisfies them. For Fa, Ar, He, etc. currently we have font settings on our templates {{fa}}, {{ar}}, {{he}}, etc.iriman (talk) 10:59, 8 June 2019 (UTC)

By use of @Wynndale: idea, I put a general notice on {{Fa}} template for a somehow long term maintenance on Farsi wiki. iriman (talk) 15:21, 13 June 2019 (UTC)

Hi again, could someone please take this issue in hand: Setting the page content language for new wiki pages automatically on page creation iriman (talk) 05:51, 17 June 2019 (UTC)

A quick update; {{Ar}} and {{Ps}} are no longer transcluded; {{Rtl}} appears on one page to format text; {{Fa}} and {{He}} are confined to categories, as are some templates for languages not present on the wiki. --Andrew (talk) 07:54, 21 June 2022 (UTC)

@Iriman: I looked at your issue when assessing means to hinder users from uploading files without licenses. Unfortunately, I have not found any solution that sets the page language automatically. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:29, 3 August 2022 (UTC)
Thanks. I think there's not problem with archiving this old section as also the main issue is solved. iriman (talk) 14:21, 10 August 2022 (UTC)

@Tigerfell: is there anything actionable here? mentioned in header is closed with "You're better off talking to the wiki admins really - if they have a change they want us to make then fine but we're not mediawiki experts." Do we need to request something? Is there any other page with similar problems? Mateusz Konieczny (talk) 13:36, 3 September 2022 (UTC)

Iriman requests some sort of automated edit that is triggered after a page creation. I currently do not know any way to do this. One might need to look for an extension ... (?) --Tigerfell This user is member of the wiki team of OSM (Let's talk) 21:37, 6 September 2022 (UTC)

Thank you guys for following on this. Let me add more info on the problem I see:

Someone tries to create a new page in a right-to-left language. I assume that the page have a prefix like ar: or fa: in title so it can be identified as a rtl page. Having the content language automatically set in the appropriate lang has two benefits:

  1. User has the option to look at preview of page before actually saving it. To try this out: I try to create page fa:test, when I click the preview button to review, content is displayed left-to-right and this doesn't look well specially if the content is a mix of rtl and ltr.
  2. User doesn't need to manually change content language of page, since it is automatically set.

Transition to use data items when this can be done without loosing information

Hi I have experienced an editor who claims that we have not decided to start using the data items. In this edit the user reverted my edit resulting in a net loss of information because the data item have a lot more combinations: combination: shelter_type bench table drinking_water water_source floor:material building access image fireplace mattress locked distance_from_road year_of_construction water_source bin wikidata capacity

I therefore suggest that we discuss here and later vote about start using the data of our fantastic data items when no data is lost doing so as in the example case above.--PangoSE (talk) 10:56, 15 January 2020 (UTC)

This specific case is a separate issue, for example distance_from_road=* seems to be dubious at best and in my opinion it should not be used at all. I will start a discussion on the tagging mailing list to get wider opinions Mateusz Konieczny (talk) 11:08, 15 January 2020 (UTC)
No, you did not mention this at all in you revert. You also did not discuss this in the talk page of either the tag in question nor the discussion page of the data item.--PangoSE (talk) 11:18, 15 January 2020 (UTC)
Yes, initial revert was done with justification "relying on fetch data from wikidata data items is not desirable". I am disputing claim that it resulted in "net loss of information". I will add further comments about what I consider as mistakes on Item talk:Q5007 (starting from wikidata and image tags). Mateusz Konieczny (talk) 11:27, 15 January 2020 (UTC)
For what it's worth, I was also going to revert the change, but I see Mateusz Konieczny got to it before me. --Jeisenbe (talk) 13:33, 15 January 2020 (UTC)
Also I'm not in favor of fragmentating the discussion away from this wiki. Please urge wherever you share this that they contribute here.--PangoSE (talk) 11:20, 15 January 2020 (UTC)
Certainly, any external notification should mention that it is 100% invitation and that comments elsewhere are going to be ignored. Mateusz Konieczny (talk) 11:24, 15 January 2020 (UTC)
For more general issue - I have several problems with data items. Main ones for me are
  • Adding data item to the Watchlist means that it gets filled with "used added translation in Hungarian/Korean/etc" or in other language that is 100% unfamiliar to me where I am unable to distinguish correct edit from clear vandalism, AFAIK it is impossible to avoid it and makes easy to miss edits that I can review
  • Watchlist is filled with things like Item talk:Q5007‎‎. I really prefer to not use database identifiers as titles, especially in cases where obvious human-rememberable titles are available
  • As a direct result of watchlist issues - quality of data in data items is significantly lower than data specified in the article text (including template parameters)
  • poor page titles (compare Item:Q5007 and Tag:amenity=shelter), naming collision with the main Wikidata (see )
  • Editing interface requires JS, page loads for far longer and interface elements jump around as page continues to load
  • Inability to copy content, edit it outside browser as text and copy it back
  • Tying OSM Wiki to one more third-party system and relying on it, one more part that may break
  • Making editing Wiki more complex, now people need to edit in two different places
  • Overall, due to UI issues I am not a fan of data items and oppose migrating to them
Mateusz Konieczny (talk) 11:24, 15 January 2020 (UTC)
Thanks for taking the time to write this. I like your arguments and I'm somewhat surprised that we have rolled out a system and encourage people to used it but when they do, the community cannot accept the information to be displayed in the wiki.--PangoSE (talk) 15:02, 15 January 2020 (UTC)
PangoSE I'm very unhappy with changes you made. Some tools use wiki and not data items (for ex taginfo). Removing stuff from wiki destroy usefull information for those tools. Keeping it in the wiki without editing the data item allow all info to be used by both wiki-based and dataitems-based tools.
in fact I'm unhappy with the write acces to data items that has been done too early, all major tools must first be migrated to the dataitems.
unfortunately for the moment the data items lead to a desyncronization of the information according to the method used to access it, which is the opposite of the arguments used for the experiments.
Marc marc (talk) 12:03, 15 January 2020 (UTC)
Hi Marc, based on the other answers here, maybe the data items should as you suggest be read-only until wider adoption is agreed. Personally I would rather transition to a wikibase-only solution parsed from the wiki and the wiki deprecated, instead of this half-half solution that is brittle/confusing/not agreed on. I like the wikibase-editing approach and consistency better, but this is my subjective taste.--PangoSE (talk) 15:02, 15 January 2020 (UTC)
I also oppose this idea. Editing the data items is more difficult than adding the text-based templates and maintenance is harder. It is nearly impossible to follow the changes to a data item, because each change is recorded separately. Right now you can understand the whole history of a Tag: or Key: page, which describe the basic features in Openstreetmap, just by looking at the page history. If we instead switch to pull everything from the wiki data item, you will have to look at 2 pages histories to understand what has happened. I don't see any benefits to outweigh these problems, especially for the English language pages. --Jeisenbe (talk) 13:33, 15 January 2020 (UTC)
I disagree that it is harder than templates and text - I personally dislike wiki-templates if the data is suitable to model in a wikibase instead (which it is in this case IMO). This is the reason I edited the combination-property on the item instead of the wiki-infobox, I remind you that I saw nothing anywhere discouraging me from doing this. I agree that having both side by side is confusing and not a good idea. Wikipedia and Wikidata work because they are not side by side and it is quite clearly define what goes where. It seems we don't have the contributor base or manpower to succeed in copying this WMF wikidata-way at the moment and the result is bad. What about uninstalling the wikibase from the wiki and create a wholly separate OSMbase website where the bot can run loose and whoever want can contribute? This would as I see it solve all the problems in one go: no more confusion, no more editing items instead of wiki and we can choose to copy information from the OSMbase site if we want to and reference properly.--PangoSE (talk) 15:02, 15 January 2020 (UTC)
I agree with Mateusz and Jeisenbe, the complexity added with the wikidata items makes it harder to understand what is going on, and while I follow quite some wikipages with respect to their changes, I do not do it for our wikidata items because of too much noise. —Dieterdreist (talk) 18:49, 15 January 2020 (UTC)

@Mateusz Konieczny: I appreciate you spelling out in detail the pain points you're experiencing with data items. I hope we can chip away at these problems without making data items read-only or shunting them onto a less integrated site, so that OSM can continue to benefit from increased software integration (that isn't bottlenecked by taginfo) and improved translation coverage.

I think I misunderstood you the other day when you asked how to filter your watchlist in Slack. Here are some possible solutions to the noise that you're experiencing on Special:Watchlist. These solutions also work equally well on Special:RecentChanges and Special:RecentChangesLinked:

  • To filter out changes to data items associated with the wiki pages you're watching, uncheck the "Show data item edits in your watchlist" setting in your watchlist preferences. (The watchlist page itself also has a checkbox in the "Filter changes" dropdown to filter them out temporarily.) The checkbox was misleadingly labeled "Show OpenStreetMap Wiki edits in your watchlist" until just now. There are many such messages that refer to the {{WBREPONAME}} variable. I've fixed all the messages I could find, but only in English. This GitHub issue tracks changing the MediaWiki configuration to resolve the ambiguity across all languages.
  • To filter out all edits to data items, click the  Namespaces button in the filter panel, check "Item", and click "Exclude selected". You can click the bookmark button to save the filters for next time.
  • To filter out only changes to labels, descriptions, or aliases on data items, click the  Tags button in the filter panel, check "Data item terms", and click "Exclude selected". You can click the bookmark button to save the filters for next time. I just set up an "abuse filter" to automatically tag incoming edits going forward. (Edit: This filter is temporarily disabled due to a configuration issue.)
  • If you need to track edits to descriptions in a particular language but not the other languages, I could create a dedicated abuse filter for your language, but we should limit such tags to the most widely used languages to avoid unnecessary load on the server. That said, I hope the existing filter and tag are enough for your needs; to me, an inability to filter on specific languages would be similar to the situation with translatable templates.

@Yurik: has been working on some enhancements to this wiki's interface that will integrate data item editing into the main wiki reading interface. That should result in more intuitive editing than the existing template system without the excessive clicking that the default Wikibase interface currently requires.

I think it's fair to say that editing either the wiki pages or the data items is still too confusing to inexperienced wiki editors (which is to say, inexperienced and experienced mappers alike). I value data items but also think we should make sure they coexist with key/tag description pages for now, rather than coopting them. Data redundancy isn't ideal, but we already flag some inconsistencies through maintenance categories such as Category:Mismatched onNode. If these inconsistencies become too overwhelming to resolve manually, we could have bots like Yurikbot do the gruntwork of automatically synchronizing the data items with pages or vice versa. This kind of synchronization is impractical if we rely solely on wiki pages and translations of wiki pages, as evidenced by the 1,278 keys and tags that are documented inconsistently among wikitext translations.

 – Minh Nguyễn 💬 19:11, 15 January 2020 (UTC)

I would want to ability to exclude from watchlist edits for labels, except specified languages (Polish and English in my case). Weird setups like filtering RSS or abuse filters are not really solving the root problem with watchlist. Note that watchlist pollution affects everybody, not just me and this is a basic tool in wiki. Solution to this problem should be accessible to normal users. Mateusz Konieczny (talk) 19:15, 16 January 2020 (UTC)

I agree, we can do more to improve the ergonomics. Using abuse filters in the manner described above is not uncommon with MediaWiki instances, but it does require some adjustments to the default configuration.

At a certain point of granularity, we’re really talking about the ability to query changes based on arbitrary criteria, which is beyond MediaWiki’s built-in capabilities regardless of the page’s content model. Such querying is relatively straightforward with tools like Quarry. But if the primary requirement is that the tooling is 100% built into MediaWiki, then there’s no good workaround for the fact that translations live on the same page as each other. This same limitation applies to various templates around here, to the extent that anyone cares to watch templates.

On the other hand, keeping translations together means they’re less likely to get out of sync, and sharing untranslatable properties among translators keeps our tagging system from fragmenting between language communities. If hypothetically we were to abandon data items, we would still need a solution for these problems. But an alternative translation solution, the Translate extension, has gone nowhere. Meanwhile, if we were to require that every key/tag infobox draws its data from a shared template instead, I’m not sure that would be any more ergonomic, except for the few of us who are comfortable hacking on templates. (As it is, even the infobox parameters being discussed above require plenty of clicking around in the visual editor, which is enabled by default.)

This is also a good opportunity to examine the practical problems with relying on non-core tools. (I hesitate to call something run entirely by OSM contributors, often on OSM infrastructure, “third-party”.) If filtering the watchlist were to require a user script or potentially a lightweight tool that uses the MediaWiki API, would that be any more unusual than our reliance on taginfo for analyzing OSM tag usage or OSMCha for supplementing the OSM website’s changeset history functionality?

If the concern is about learning curve and discoverability for new contributors, then the solution is to embed these tools in the wiki, which we can do by writing gadgets. If the concern is that only a limited subset of the mapping community has the wherewithal to contribute to data items or tooling around them, then I would just take a look at the limited number of people who maintain our templates today as a counterpoint. The power of a wiki is its openness to new contributors being bold with new ideas, but that flexibility has long been hamstrung by concerns about compatibility with screen scrapers used by taginfo and OSMBC, neither of which are actively maintained, making it difficult to revamp poorly architected templates.

I think the ultimate goal should be that every mapper should be able to improve our documentation and shape the community’s understanding of our tagging system without having to learn a foreign language (human or computer). None of our schemes accomplishes that, not even close. But a system that has localization and programmatic access built in is far superior to a system that can only be localized or parsed thanks to layers of templating hacks and unmaintained regular expressions.

Finally, since Gmane is down and I can’t respond directly to the mailing list thread about this discussion, it should be noted that data items are an approach to managing documentation about tags; its adoption is completely orthogonal to the inclusion of Wikidata QIDs in the OSM database.

– Minh Nguyễn 💬 23:46, 16 January 2020 (UTC)

Re: "...[it] keeps our tagging system from fragmenting between language communities. If hypothetically we were to abandon data items, we would still need a solution" - this is assuming that allowing tags to be used differently in other countries and language communities is a problem that must be stamped out, rather than a normal result of a global project which is adapted to local conditions in many different countries and language areas.
The watchlist is currently an automatic way of maintaining the wiki pages: anyone who edits a page is signed up to get notifications about any changes that happen. That's why I am watching almost all of the Tag: and Key: pages listed in Map Features: I have edited most of them at one time or another, and I now am aware if they are changed. There are a dozen other users that are being notified of each change for the same reason, and this prevents vandalism and mistakes. But watching the wiki data items is nearly impossible: there are far too many email notifications to manage as less than a full-time job, since every individual change in every language is a notification.
Re: "I think the ultimate goal should be that every mapper should be able to improve our documentation and shape the community’s understanding of our tagging system without having to learn a foreign language (human or computer)" - in this case we should remove the ability to directly edit wiki data items and use get things like the "combinations=", "see also=", "requires=" and "onNode, onArea" from the plain text of the wiki page by using a natural language parser. This could still use the wiki data items as a back-end, but it should be designed in a way that does not require any maintenance. Perhaps it is better if tools like taginfo can do this step automatically. I don't know if algorithmic language processing is anywhere near good enough for this purpose, but the goal should be encouraging human-readable, well-written wiki page text (plus some relevant images). All of this data item distraction is taking up time that could be used improving the human-written, human-readable documentation that should be in the main text of the wiki pages, not in a secondary database. --Jeisenbe (talk) 02:46, 17 January 2020 (UTC)

Ignoring its potential to the wider OSM project beyond the wiki, Wikibase is a tool for managing the content of infoboxes. Just as infoboxes aren't a replacement for body text, data items aren't a replacement for body text either. As things stand, everything in a data item should already be shown in the key or tag description page's infobox. Eventually, I hope you'll be even able to click a edit button next to each row in the infobox, type the new value inline, and save without ever leaving the page. But there will always be a place for human-written, human-readable documentation regardless of data items. The body text is a great place to explain the real-world phenomenon expressed by the tag, how to find such things on foot or in imagery, common mistakes to avoid and how to fix them, external resources for learning more about the topic, and so on. For example, very little of the body text in Tag:emergency=siren or Tag:service=driveway overlaps with the infoboxes.

Some variability is inevitable and preferable in such a global yet hyperlocal project as OSM. However, most of the interlanguage discrepancies on this wiki are unintentional. (This list links to items for which inconsistencies were identified when seeding the original data items with data parsed from key and tag description pages and their translations, minus the inconsistencies that have since been resolved thanks to the data items bringing them to light.) Indeed, the few intentional differences seem to conflate languages with countries. The rest are symptoms of the decentralized management of infobox data – inconsistencies that are just as problematic to mappers as they are to any validator, editor, or data consumer that would be built upon the wiki's documentation. After all, most people who edit an infobox won't think to synchronize all the other languages' infoboxes. In the days before Wikibase, someone might've proposed that the infobox in Tag:amenity=telephone and all its translations be populated by the contents of a shared Template:Tag:amenity=telephone. Then maybe someone would've proposed a boilerplate template you could fill out, and then localized versions of that boilerplate template. Wikibase formalizes this functionality for all tags without the overhead of countless error-prone templates.

I'm a bit puzzled by your suggestion about natural language processing. My point was that Wikibase and the data items' properties are already fully localizable, and many languages now enjoy translated tag descriptions in iD because the barrier to creating a translation is so low compared to standard wiki pages. If the problem is that this Wikibase installation is half-baked in any way, yet-to-be-written NLP software isn't a solution. Nor is less sophisticated screen scraping: there's no point to a freeform, human-readable wiki page if it has to be formulated a certain way for a parser to pick it up. Anyways, no one is suggesting that body text be generated from data items, only that the infoboxes draw from data items (which are fully localized) instead of template parameters (which require not only English language skills but also potentially wikitext skills). Even then, I would caution that there's no need to rush and remove template parameters until the tooling around editing and watching data items becomes more mature.

 – Minh Nguyễn 💬 06:28, 17 January 2020 (UTC)

@Jeisenbe: I take it that you enabled the "Email me when a page or a file on my watchlist is changed" and "Add pages and files I edit to my watchlist" preferences? If you're receiving e-mail about every granular change to a data item, I can definitely understand that frustration. Have you considered disabling watchlist e-mails in favor of Special:Watchlist, which can group repeated changes to the same page or data item (as long as you keep "Use non-JavaScript interface" disabled)? I'm currently watching about 500 data items, but the automatic grouping keeps the noise down, and I'm trying to get the translation filter back up and running. If you prefer e-mail or a feed reader, perhaps you could configure your client to filter out notifications about data items. – Minh Nguyễn 💬 06:46, 17 January 2020 (UTC)
"Have you considered disabling watchlist e-mails in favor of Special:Watchlist, which can group repeated changes to the same page or data item (as long as you keep "Use non-JavaScript interface" disabled)?" - I am using solely Special:Watchlist and it is also not capable of handling data items (unable to exclude translation edits in languages that are unfamiliar to me and show other edits). I am unable to keep them on watchlist as label-translation edits to them lead to an unreasonable spam. I never used email notifications Mateusz Konieczny (talk) 10:22, 17 January 2020 (UTC)

Hi @PangoSE: and thank you to have started this discussion. It seems we'll have to discuss, contribute and wait a bit more before DataItems be adopted as wide as wiki is currently in a large variety of tools. WikiData, DataItems, @Yurik: and other contributors works bring here a lot to samentical information quality and benefits will surely be far more important than preserving wikicode edition on a long term basis. As few concerns raise about how such tools are deserving mappers comunity, I find myself each time more surprised on how changes are first of all critisized and pretty not understood. As a wikieditor I just can't wait for a better DataItem integration in as many tool as possible. For instance, it's currently under discussion with JOSM team to take the good of this solution to produce useful and translated presets. Let's keep going with this good work and positive feelings. Fanfouer (talk) 20:00, 15 January 2020 (UTC)

I never liked the "Wikibase" related changes to our wiki and felt this was driving things away from a relatively simple schema accessible to everyone, into an expert-only realm that required much more domain knowledge to actually make a change. I do not want wiki editing to be (even) more complex than mapping is; most steps in the "Wikibase" direction seemed to me to complicate things, or at least rely on some experts to make some things available that are easy to use (but if you want something else it's template madness). I usually kept quiet because I didn't want to ruin the fun for the Wikibase advocates as long as the "normal" use of the Wiki was not hindered too much, but if people start treating the "Wikibase" part as the master system and everything else as "derived content", and you are forced to understand the "Wikibase" stuff to participate, then the buck stops for me and I am in favour of throwing out the lot. --Woodpeck (talk) 14:51, 17 January 2020 (UTC)

Same remarks apply to wikicode and templates. It is retricted to a small community mastering the edition of wikicode to change anything. Let's call it the OSM community. Fanfouer (talk) 16:05, 17 January 2020 (UTC)
I agree with Fanfouer here. I think much of this discussion is based on an unmerited bias towards wikicode. Lets face the facts:
  1. wikicode as technology is +20 years old and besides adding Lua not much has changed
  2. Wikicode might look pretty but it is notoriously hard to parse and a bad choice if that is your top priority
  3. Wikibase is a fairly new technology with much improved data consistency and interoperability.
  4. wikibase items can be improved from e.g. inside josm if we would like that
  5. improvements to the documentation in items reach everyone, improvements in the wiki might only reach a minority understanding that language
I have the impression that with well documented items with qualifiers - I'm not so sure we need the body text anymore to explain use of tags. People in doubt can ask on a mailing list or on the talk page of an item. This might cause a steeped learning curve, or might not because the presets in both josm and ID are very nice and helpful and ease my memory so that I font have to remember a lot of tags. With data items we can have a mouse over popup that defines any tag the user sees on the screen. This is wonderful!--PangoSE (talk) 21:19, 17 January 2020 (UTC)
  1. "not much has changed" - I consider it as a strong benefit. It means that there is much larger pool of people familiar with it. Old technologies are often worse than new technologies, but "X is an old technology, without breaking changes for a long time, familiar to many" is a strength, not a weakness
  2. easy to edit, hard to parse - again, I consider this tradeoff as a strength. OSM Wiki is already hard to edit. Making it even harder, just to make parsing of data easier seems a bad change. Especially as data in the infobox templates is parseable and is already used, for example in taginfo!
  3. I agree that keeping data in one place rather than in several is an improvement. But I am not convinced that it is so significant to make data items net positive.
  4. Why we would want to allow editing summary of the article (template parameters/data items) without looking at the article? It will just encourage mismatch between article text and article summary
  5. Can you give an example of some data item that without translation gives useful info? More than image + usage on way/node/area/relation + in use/de facto/deprecated/approved status already displayed by an infobox? I would expect that it is not enough to understand or use the tag.
I am pretty sure that qualifiers are not enough to replace entire article text, though it could be interesting to see this in action. Can you give examples of some complicated tag documentation article and its full replacement in the data item? (BTW, thanks for presenting your arguments!)Mateusz Konieczny (talk) 10:06, 18 January 2020 (UTC)
@Jeisenbe: -- RE: "Re: "...[it] keeps our tagging system from fragmenting between language communities. If hypothetically we were to abandon data items, we would still need a solution" - this is assuming that allowing tags to be used differently in other countries and language communities is a problem that must be stamped out, rather than a normal result of a global project which is adapted to local conditions in many different countries and language areas.
You are equating regions and languages. The language of the wiki should not be the deciding factor of what should be used where. I could be a Russian-speaking person living in Brooklyn/New York (huge community there, with older generation not speaking any English), or Russia (many different locales), or any other place. Portuguese is spoken in Portugal and Brazil - very different mapping communities. Regions on the other hand could have different rules. But those differences must be documented, hopefully in every language, to make sure everyone understands them including all the data consumers. So far I only know of one case like this -- Key:noexit is allowed on ways, but DE:Key:noexit prohibits it. Most other cases are the result of stale documentation - thus a huge documentation problem. Please see storing geographical differences and the following section about locales. --Yurik (talk) 05:04, 19 January 2020 (UTC)

I find myself disagreeing both with those who want to abandon data items and with those who want to abandon ordinary prose on wiki pages. I think we're all going to talk past each other ad nauseam if we only consider extreme measures. On the one hand, it's ironic that that we're mappers who spend much of our time literally making the world machine-readable through tags, yet we can't accept some structured metadata as a complement to our tag documentation. On the other hand, anyone who thinks we can replace prose mapping documentation with data items should click on Special:RandomInCategory/Tag descriptions a bunch of times and try porting all the body text to the corresponding data item – I think you'll be mired in proposing new properties and qualifiers in Talk:Data items for some time to come.

The issue of unintentional discrepancies between infobox translations is actually a significant problem. If the wiki is internally inconsistent on basic facts like whether a particular tag can be used on an area – in hundreds of cases – can validator and editor developers trust the wiki? Or will they be forced to march to their own tune and bring mappers along with them? Wikibase carries the potential to make the wiki more relevant and harder for tool developers to ignore. Isn't that good for the wiki? But imagining that Wikibase had never been installed, would you favor factoring out each English tag description page's infobox code into a template such as Template:ValueDescription/amenity=telephone, to centralize language-agnostic details like |onArea = and |implies =? What about the English template and parameter names – would we rename the parameters to be panlingual or insert comments in every language? Or should everyone learn English in order to contribute to the infoboxes?

The guide for creating a translation of a tag description page is full of wiki jargon and glosses over lots of things that make it difficult to understand the text that one would be copy-pasting. The Wikibase interface also uses some jargon like "statement" and "qualifier", but all those terms are translated, and a translator doesn't have to bother with anything but the description anyways. It's little wonder that, for instance, there are 1,538 feature description pages in Polish but 2,017 data item descriptions in the same language. (It's even more pronounced in other languages: 41 times more descriptions than pages in Vietnamese.) I look forward to the Polish community eventually writing up full-fledged mapping how-tos for the remaining 479 data items and any others that get Polish descriptions in the meantime, but let's not make perfect the enemy of the good.

Taginfo has been brought up many times in this discussion, but it rather proves the point that this wiki needs structured metadata. Taginfo's wiki scraper is quite involved, but it can't deal with slight variations in wiki syntax or the annotated lists of valid values or related tags that often appear in the page body. [1][2] Validators can't use the taginfo API to flag usage of deprecated tags, so every editor has its own logic. [3] I don't mean to disparage taginfo: its specialty is analyzing the OSM database, not making the wiki more digestible. But the scraper does keep us from modernizing templates like {{ValueDescription}}. We can't for instance remove the redundant "File:" from |image = and |osmcarto-rendering-area = or automatically derive |key = and |value = from the page title without having to also hack on Ruby code.

@Mateusz Konieczny: You might see the constant hum of data item changes in your watchlist as nothing more than noise, but to me it's evidence that the wiki is growing beyond what it was before, becoming more relevant to a larger swath of the OSM community. I feel bad saying you have to put up with daily inconveniences for the sake of this growth. As an administrator, I view it as my responsibility to collaborate on solutions for the inconveniences you're experiencing. Your claim that data items are more difficult to edit than infobox templates is intriguing. So far, all I can surmise is that there's a lot more clicking, and that you need to keep other tabs open for context while you edit the data item. If these or other usability problems have soured you on Wikibase, then we should explore each of those problems, perhaps in new sections of Talk:Data items where the focus can be on improvement rather than elimination.

(Sorry for not responding to each of your above bullet points one by one. It's difficult to do so in this talk page format. In my opinion, the mailing list would've been a less confusing place to quote and reply.)

 – Minh Nguyễn 💬 07:03, 19 January 2020 (UTC)

"wiki is growing beyond what it was before" the difference is that with wiki pages I am intentionally not watchlisting for example German translation page. Data items are forcing me to watchlist all translations. That is why I am using Special:Watchlist, not Special:RecentChanges, Maybe data items have overall better UI and people prefer structured interface. Even at cost of horribly long loading time and slower editing speed. But is there any evidence that data items are overall more accessible or used more? Mateusz Konieczny (talk) 14:54, 21 January 2020 (UTC)
"So far, all I can surmise is that there's a lot more clicking, and that you need to keep other tabs open for context while you edit the data item." - horrible load time, each change must be saved separately, changes now require editing both description and a completely separate page Mateusz Konieczny (talk) 14:54, 21 January 2020 (UTC)
"the mailing list would've been a less confusing place to quote and reply" - I am not going to defend talk page interfaces in mediawiki, this is a clearly horrible hack that really deserves to be replaced. Though for OSM Wiki specific discussing it on Wiki seems a much better idea that using a separate forum like mailing list. Mateusz Konieczny (talk) 14:54, 21 January 2020 (UTC)

Data items - displaying P16 in Wiki lists

More and more data items are translated in other languages (e.g. German). Due to the translation of the label it is difficult to recognize the nativekey behind it in the Wiki, at least working in the Wiki is no longer comfortable. This is especially true for special pages like "Recent changes" or "Watchlist". Therefore I would like to see that these pages in the Wiki always show or list the permanent key P16 instead of the label in the respective display language. - Is there any way to change this? Where would I have to ask this? In the meantime, the only solution is to change the display language to English. Regards --Chris2map (talk) 16:16, 5 June 2020 (UTC)

What you mean by nativekey and P16? (in my case "solution" is to not add data items to watchlist and treat them as separate project, unrelated to real OSM Wiki - though it would not help if someone wants to have data items on a watchlist) Mateusz Konieczny (talk) 16:40, 5 June 2020 (UTC)
You could move the labels of the items concerned to be aliases instead. @Yurik: Any other ideas? --Andrew (talk) 16:54, 5 June 2020 (UTC)
OK I could ignore data items and exclude the namespace :item from watchlist. But if we gonna ignore them, who cares (maintains) about them? - Don't get me wrong. I'm not keen on it. - I think a further separation of the data items from the Wiki must be avoided. Otherwise there will be 2 competing wikis for OpenStreetMap and it is not clear anymore which one will apply. So improving integration or wiping away data items. --Chris (Chris2map (talk) 18:21, 5 June 2020 (UTC))

disagreement in the community about data items and tag pages: how to proceed?

Recently I observed an edit war starting in Tag:highway=living_street, where some lines in the ValueDescription template were repeatedly removed and re-added to start/stop the use of data items for this tag, and one user proceeding to delete the data item itself. For the moment I have locked the page and data item before this gets out of hand any further.
I have commented on Talk:Tag:highway=living street and asked for more cooperation instead of more confrontation, but as the disagreement is not about that tag page itself but the use of data items in general, the discussion really should be on this page here.
I'm putting this here in the hope that we as a community are able to find a better solution than an edit war. --Lyx (talk) 22:07, 23 May 2021 (UTC)

In my opinion, given that there is no consensus to start blanking infoboxes doing this is not OK. At least on English language pages, not sure about translations. Mateusz Konieczny (talk) 08:02, 24 May 2021 (UTC)
This is mainly about translations and giving access to the same level of information to non-english mappers. If you only consider English then sure Data Items make a bit less sense, but please think about non-english speaking viewers. --Gileri (talk) 08:22, 24 May 2021 (UTC)
Also, please see Talk:Tag:highway=living_street#Blanking_infobox, Talk:Tag:highway=living_street#How_can_a_tag_imply_a_key.3F and Talk:Tag:highway=living_street#Conflict_about_.22info_boxes.22 for arguments already made about this issue. --Gileri (talk) 08:09, 24 May 2021 (UTC)

I also think we do need here a procedure in general. At the moment there is a duplicity of content. IMHO this could only be accepted if at first it was clearly defined what is the master content an at second the content would be automated copied/transferred from master to the other data. For all other cases we should eliminate duplicity. At a technical view it is cool that infoboxes can handle both sources of content (wiki page and data items). But here we have the issue that it is not decided which twin is preferred.
I think I understood data items are an extended offer to software and consumers. By having that database of data items there must be a way to check and maintain them in the wiki. So the infoboxes seem the logical place for showing the content of data items and provide the link to edit them. From my view there are some major disabilities or missing features to be fixed, before immediately and completely change to data items in infoboxes:
1. The fixed native key/tag name of an item must show up in lists like recent changes and watchlist (not the label which might be translated).
2. The human readable name of an item must show up in email notification of a watched item (not only the item number).
3. There should be the ability of an edit comment to edits in data items.
If these points are solved it would be fine to me exlusively use data items for content in infoboxes and remove them at the wiki page.
With that step we'll have to decide, which rows or parameters in infoxboxes should "move" to data items. There are ones being predestinated for data items (like "use on nodes/ways/...", status and image). Others like the short "description" might be also a good idea. With "requires", "implies" and "see also" it is more complex. The topics of a key/tag like "requires", "implies" and "see also" might be better placed and treeted at the wiki page, due to having more flexibility to describe them.
We should think about to limit (and maybe reduce) the content of the infobox. It is developed as a short information on a key/tag and never could cover all content. The same applies to data items. So instead of struggling with pressing more and more information in data items, IMHO we should limit it for now to have a well working short content database and first define the use in the wiki and remove duplicity. E.g. by moving "image", "description", "status" and "use on..." completely to data items.
What would be the procedure to proceed? Some kind of proposal? By the way, the continuation of the discussion is hard to find cause it doesn't show up in TOC. regards --Chris2map (talk) 10:34, 24 May 2021 (UTC)

Thank you for you detailed input Chris2map !
I agree that the points you raise makes moderation/review harder. Do you think that having a readable watchlist/log/comments (metadata) are more important than having up-to-date content ? Also a big advantage of Data Items is that one can see edits on the one Data Item "page" instead of in each of 10+ languages, which they most probably can't understand the language for most of them. So those advantages may offset the problems you pointed out. --Gileri (talk) 20:20, 29 May 2021 (UTC)
The maintaining abilities aren't more important than the content. Nevertheless those are important to handle with the content and keep it right and up-to-date. But the underlying issue is how to switch to data items as base for the content of the infobox. Up to now the valid content is the one on wiki page and data item is only determined to be an extension with (automatically) copied data from wiki page. There has to be defined and described what changes are going to be made and how to manage the content data in future. Then it will affect all pages and there must be checked and decided for each page and item, if item data matches the actual page content, before switching infobox. Otherwise content showed on mismatching wiki pages would change at one swoop, even without a note in page history. So maybe it must begin step by step and could be started with the "description", the more so as "description" in data items is already being used by iD editor. I agree that editing the parameters in different languages is more forward at items than at wiki pages. --Chris2map (talk) 22:22, 29 May 2021 (UTC)
Okay, so if I understand you correctly you oppose a global change to infobox in one swoop. What I did, and what the conflict is about, is changing one or two infoboxes attributes to use Data Items, after manual verification that the content is up-to-date.
Also, you indicate that moderation issues makes it hard to follow Data Item changes. But currently one has to follow both Data Items and each and every language version of the tag page if they want to make sure there are no errors. After using Data Items, that makes a lot less content to follow, so that is a net gain, even with the current issues. --Gileri (talk) 09:12, 30 May 2021 (UTC)
Hi, I don't refer to the initiating conflict. My request is what global solutions are there and how to get there (to dissolve duplicity of content data). I'm still open with my position. Actually I would be glad if we could move "description", "use on..." and "status" to data items, and could maintain them in one place. But I think if we (two) do this simply in one swoop by changing templates of infoboxes, there would occure at least 3 problems popping up: 1st) An outcry of part of the community. 2nd) How to ensure that the more up-to-date data has been adopted (if there are discrepancies between wiki and item, as I mentioned above). 3rd) How should the data or parameters be deleted from the wiki pages? So I'm definitely in favor of improving the current situation. Hence my consideration of whether a small step is somehow practical. Do you have an idea for a bigger swoop? --Chris2map (talk) 11:25, 30 May 2021 (UTC)
I don't have ideas to change every infobox at once. Even if I did, based on the resistance on some vocal users for the tiny change I did, I think such an endeavor is bound to fail, sadly. But I would be glad someone with more time and energy on the issue found a way to both solve the technical issues, and convincing that structured data in the wiki for OSM, a structured data project, is a good thing. --Gileri (talk) 11:37, 30 May 2021 (UTC)
Couldn't an update to the template with a check for correct data duplication with warning or error messaging be a solution ? The new infobox would display the wikidata item if it would fits the infobox content from the wiki page. If there is inconsistencies, or wikidata is non existent both values could be displayed in the infobox and the infobox template could generate a "clean-up" or "warning" ambox or a category as you like. This would allow for a gradual transition, a new global changed infobox template but for all at once, as data inconsistencies are clearly displayed and the amboxes or category can be used to trace data duplication errors. Even after a transitional period, I expect that many wiki editors will not feel familiar enough with wikidata to edit it whenever a tagging addition or change is eminent. So the "transitional" template might as well work as a permanent solution and provide more efficient tracking tools for data duplication. --Bert Araali (talk) 12:32, 30 May 2021 (UTC)
"This would allow for a gradual transition" - what should be done only if there is a clear support for such transition. ""clean-up" or "warning" ambox or a category as you like" - such categories exist already, see Category:Mismatched wikidata, Category:Mismatched onArea etc. Mateusz Konieczny (talk) 11:39, 31 May 2021 (UTC)
What I am missing in this discussion so far are ideas - by those opposed to the use of data items and of course others as well - how to make sure that mappers who do not speak English can participate in OSM. In other words, how do we keep documentation consistent about language versions. And if the idea is "Someone monitors changes and adapts the existing translations" I would like to know who that "Someone" is and if "Someone" agrees to take the job. --Lyx (talk) 15:36, 31 May 2021 (UTC)
Actually, for keeping translation in synch data items are worse than OSM Wiki pages. There is no effective way to notice that something is changed (as watchlisting data items fills watchlist with translation updates in all languages, including ones where you cannot review changes). That is why I am against blanking infoboxes, it would Watchlisting wiki page in your language and in English is right now the best solution. And for parameters in infoboxes like onArea - I would be happy to generate list of mismatches if anyone would be interested and keep it up to date. If anyone actually interested in fixing such mismatches - which language is interesting for you? Mateusz Konieczny (talk) 16:19, 31 May 2021 (UTC)
I think you missed the "do NOT speak English" in my comment above. I don't worry so much about Wiki translators or editors but about readers who just "consume" wiki pages to find out about tags they want to use. With data items they could get at least rudimentary information consistently auto-translated instead of (in worst case) nothing that they can read. --Lyx (talk) 18:55, 26 March 2022 (UTC)

Detecting differences between infoboxes in English and translated pages

If anyone would be interested in listing differences between infoboxes in English and in some specific language, please let me know. I have a complete toll allowing to produce such list, and in smarter way than current available one (skips some irrelevant differences).

If you are interested in using something like that - which language you are interested in? Mateusz Konieczny (talk) 20:32, 4 December 2021 (UTC)

what do we mean when we talk about consistency between language versions?

I see three different forms of consistency that we could talk about, and I like to describe them using examples. Please note that these examples are NOT valid tags in OSM (at least not as far as I know) and are only used here for illustration.

First form of consistency is "One specific tag should always specify the same kind of object regardless of the language used in the area where the tagged object is located". So assume we had a tag "biome=tundra", and it would be used for tagging areas of land where the vegetation is limited by low temperatures and short growing seasons. Then if in a specific language version this tag was documented as a tag to be used on nodes instead, or to be used for tagging e.g. railway stations, that would be a breach of consistency. In my opinion that kind of consistency breach would be unacceptable.

Second form of consistency is "The same kind of object should always be marked with the same tag". So if there were one language documenting that a "land area with vegetation limited by low temperatures and short growing seasons" should be tagged "landscape=cold_steppe" while in other languages it would be called "biome=tundra", that would be a breach of this form of consistency. I personally would consider this kind of inconsistency as mildly annoying, but not a big problem.

Third form of consistency is "The same tag should have the same useful combinations in all language versions". So if some languages documented that "biome=tundra" could be combined with "permafrost=yes" and other languages did not, this would breach the third form of consistency. Personally I would not see this as a problem at all; if that combination is useful someone will get around to document it eventually.

What do you think, are there other forms of consistency you care about or do you disagree with me about the importance of these forms of consistency? Let us know, please. --Lyx (talk) 20:23, 26 March 2022 (UTC)

1 is important to me, 2 is nice to have but not critical, 3 is not a good idea at all as it disallows making a new translation page with the most important info and skipping less important parts. Mateusz Konieczny (talk) 20:48, 26 March 2022 (UTC)
@Mateusz Konieczny: Regarding (1): I have a neighbor who prefers to speak in Spanish; we share a driveway. If the users writing Spanish-language pages here insist that service=driveway should apply to shared driveways, while the English-speaking users insist otherwise, would it be proper and correct for the two of us to edit-war over the tagging of our driveway? I do agree that the tag description page in each language should be tailored for comprehension and intuitiveness in that language, but discrepancies between languages are less justifiable when they would result in different tagging behavior. This includes the basic details in infoboxes or data items. Multilingualism is important, but it also risks misunderstanding and conflict among users if taken to extremes. – Minh Nguyễn 💬 11:35, 9 November 2022 (UTC)

Usage of arearelation icons on boundaries

The use of the icons area and relation are used inconsistently across the wiki when it comes to boundaries (specifically, relations tagged with type=boundary). It is clear that area applies to relations of type=multipolygon. However, a boundaries are more complex - they are a relation of type=boundary with one or more closed ways and optionally nodes with the roles Role admin_centre and Role label. Are boundaries area, arearelation, or relation?

The table below shows the different answers given on different wiki pages.

1. Does area apply to relations of type=boundary?

Yes No

2. Does relation apply to relations of type=boundary?

Yes No

Which icon(s) should be used when describing boundaries on the wiki? —Preceding unsigned comment added by ZeLonewolf (talkcontribs) 01:12, 30 October 2020

area is basically wrong with relations, IMO - even with the simple multipolygon relation. As for now there are no different icons for different relations, only relation is available for all kind of relations. --Chris2map (talk) 17:48, 8 July 2022 (UTC)

DynamicPageList extension

A recent mailing list post by Lectrician1 got me thinking we should install the DynamicPageList extension. This simple extension adds a tag that allows any page to include a dynamic list of the contents of a category and customize some basic sorting and display options. For example, Proposal process could have a table that looks like this, populated automatically as a result of each proposal page using the {{Proposal Page}} template and sorted by the date the status was last changed:

A similar list based on Category:Key descriptions with status "de facto" could appear on the Changelog. Or these lists could even appear on Main Page to supplement {{News}}, which is very quiet (only three items for all of 2020).

The extension's official documentation includes a warning to only install it on small- to medium-sized wikis due to scalability. Fortunately, I don't think this wiki is anywhere near the scale where that issue would matter. The Vietnamese Wiktionary, one of the largest Wiktionaries about four times the size of this wiki, bravely uses it on its front page to showcase new entries. Also, I think the scalability issue is specific to performing an intersection between two categories (must be in category A and B but not C), which isn't necessary for the use case described above.

If there's agreement that this extension would be useful, we can ask the operations team to install it.

 – Minh Nguyễn 💬 02:13, 7 January 2021 (UTC)

+1 if this extension is not introducing some noticeable complexity. Is there a real risk of increased instability and poor performance if we keep enabling bunch of extensions? Here benefits seems minimal Mateusz Konieczny (talk) 10:00, 11 January 2021 (UTC)
I can't speak for the cumulative effect of many extensions being enabled, but one way of looking at it is that we have far fewer extensions installed than a typical Wikimedia wiki, while the community seems to expect a similar level of service. DynamicPageList is fortunately a relatively simple extension, befitting its relatively minimal benefits, but I think your concern is worth keeping an eye on. – Minh Nguyễn 💬 06:55, 20 January 2021 (UTC)
Symbol support vote.svg Support --Lectrician1 (talk) 15:01, 8 February 2021 (UTC)
I Symbol support vote.svg Support it. maro21 18:13, 5 May 2021 (UTC)
Symbol support vote.svg Support --Tordanik 20:52, 7 May 2021 (UTC)

By way of an update, the MediaWiki developers have reported stability issues due to intersections with very large categories on some wikis. They're planning to limit DPL to categories containing 100,000 or fewer pages, which shouldn't by itself affect this wiki: our largest category is Category:Pages unavailable in Dutch‏‎ with a mere 45,188 pages (just a bit of translating to do). However, Wikimedia's problems may warrant some investigation as to whether other performance issues could affect us. – Minh Nguyễn 💬 22:50, 28 October 2021 (UTC)

Add TemplateStyles Extension


I am looking to redoing the Main Page however I require css. This extension allows for separate stylesheets.

Any objections?

--Lectrician1 (talk) 03:52, 6 February 2021 (UTC)

Custom CSS is possible now, it just needs to be installed by an admin. I had to do this for my taginfo box replacement project. No need for a separate extension AFAIK. @Minh Nguyen: --ZeLonewolf (talk) 04:05, 6 February 2021 (UTC)
Yes, Minh and I discussed this. However I run into the issue of not being able to test the css and how it looks on a page before I commit to the actual page. I want to use my user pages to test both the Main Page Wikitext and CSS combination. Not being able to test means going through a admin is practically unreasonable. It's also nice to have publicly-available css stylesheets for easy reference and changes. All Wikimedia projects have this extension and it's been very handy to work with in the past before. --Lectrician1 (talk) 05:03, 6 February 2021 (UTC)
That doesn't make any sense, I had no problem testing my CSS without any special extension. --ZeLonewolf (talk) 05:19, 6 February 2021 (UTC)
Following up from our private conversation, hopefully your browser's built-in developer tools provide the facilities you need to prototype style rules for the main page. TemplateStyles is a nice extension to have, but it is already technically possible to implement something similar without TemplateStyles by writing a user stylesheet that an administrator can turn into a gadget or copy into MediaWiki:Common.css. Gadgets and sitewide stylesheets affect every page for every user, so it's important to scope style rules, for example by prefacing each ruleset with .page-Main_Page .bodyContent. Even then, there is extra overhead loading any page on the wiki, so consider inline style attributes if possible. TemplateStyles is nice to have because you can express more than style attributes but without adding overhead to unrelated pages. – Minh Nguyễn 💬 09:35, 6 February 2021 (UTC)
How can other users see the programmed css for a page after an admin has added it. What if they wanted to redo the main page after me in the future and reference the old css?
In my opinion, using browser tools is going to be much more of hassle for me than just having the easily-installable TemplateStyles.
I also just thought of another conflict I might run into. If I'm using templates on the main page that rely on their own css, will the css I program for the template and main page show up? Templates render based on their source page and if the source page has no css, I'm not sure this will work. The template won't be able to pick up any css references either since it's only coded presence on the main page will be {{Frame}}.
--Lectrician1 (talk) 13:53, 6 February 2021 (UTC)
Okay I tested my "possible problem" and turns out css does work for templates that are transcluded on another page.
However, can we please just add the extension out of convenience?
Evey time I want to change the wikitext, I have to copy and then reinsert the css into into my browser developer panel. There is a lot of Wikitext I'm going to have to change for the main page. This is going to be a big hassle.
Also, as I noted before, it's nice to have the css stored in a file everyone can easily reference, rather than wherever an admin has to store it ingrained in the page. --Lectrician1 (talk) 23:26, 12 February 2021 (UTC)

@Lectrician1: Any reasons to do that? Enabling all extensions possible is asking for a trouble. Also, can you finish FAQ project where useful info was lost/hidden before starting a new one? Also, please do not spam extension requests on openstreetmap/operations - posting there about every single extension you found will just make more likely that OSM-wiki related requests will be ignored in bulk. In general, feel free to start 24387427248427842784287 projects - I am also guilty of that - but, please, avoid opening issues on for example openstreetmap/operations until there is confirmation that it is a good and necessary idea. Mateusz Konieczny (talk) 10:41, 23 February 2021 (UTC)

@Mateusz Konieczny: I'm still thinking about FAQ. I also gave this 2 weeks after the last piece of discussion on this before posting an issue on the operations repo. That was plenty of time for people to respond, in my opinion. Also, this is not being implemented is limiting me from doing something on the Wiki, so I felt it was important to post it. --Lectrician1 (talk) 16:16, 23 February 2021 (UTC)

Symbol support vote.svg Support This makes sense to me, considering that as CSS becomes evermore granular as it evolves to meet the requirements of responsive design the practicality of using inline style declarations is diminished and will only continue to do so. TemplateStyles was one of the best reactions by MediaWiki to managing the growing complexity of producing web content that I've seen, and has improved the usefulness of templates on all of the MWF sites I contribute to almost without exception. It's also easy for the higher-privileged users to "ride herd" on with it compartmentalized on its own page rather than on the template itself, requiring nothing more than the standard abuse mitigation tools like page protection. I see others have suggested that editors use their browser's Dev Console instead, but that has a much higher barrier to entry and does nothing to address the larger issue which (as I see it) is: producing functional, dynamic web content now requires rather finely-tuned CSS declarations in many cases and our options are to start to find ways to create and manage them or to see the usability of our content diminish without them. —RScholar (talk) 05:52, 20 April 2023 (UTC)

Authentication from


OAuth login to Wiki is a Top Ten Task

PluggableAuth looks like a suitable extension for this.

I'm surprised this hasn't been implemented yet because the configuration for this is quite simple.

You're probably going to have to read into the specifics on your own since the various options for how users can log in can be a bit confusing.

Either way, this works and should be implemented. Here is an example of a Wiki that uses it.

--Lectrician1 (talk) 21:39, 8 February 2021 (UTC)

Enabling OAuth2 authentication between and the wiki should be the #1 priority for new features to the Wiki. The lack of this seamless authentication is often cited as a barrier to entry for participation in tagging discussions. Issues that need to be addressed:
  • What is the process for linking existing wiki usernames to usernames in a way that's straightforward for users and not a burden on admins?
  • Will the process be seamless for new users?
  • Do we have an issue in the case of name collisions? (in which an user and a wiki user of the same name are actually two different people)?
--ZeLonewolf (talk) 22:18, 8 February 2021 (UTC)
  • It seems that as long as an account on the Wiki and OSM have the same username and/or (not sure) email, then they can login.
  • Yes, it is seamless.
  • I think the emails being the same is the deciding factor.
--Lectrician1 (talk) 22:26, 8 February 2021 (UTC)
It would be great to eliminate this barrier for participation on the wiki, seems very promising! I've got some questions as well:
  • What does it mean that the process is seamless for new users? Can they just log in using their existing account without having to "create a wiki account" first?
Yes. If a Wiki account does not exist with the username and email that is returned by the client, then a new account for the Wiki will be created and the user can continue to use to login. --Lectrician1 (talk) 17:24, 14 February 2021 (UTC)
  • I understand that the plan for dealing with differences between the two sets of accounts is that users resolve these themselves (by changing their user name and/or email address so that they match, or creating an OSM account for wiki accounts that don't have an equivalent yet)? For that to be possible, there will be a co-existence of linked accounts and un-linked accounts at least for a transition period, right?
Correct. It is up to the users to decide when and whether they want to "link" them. They can do so at any time because the login process will remain the same always. --Lectrician1 (talk) 17:24, 14 February 2021 (UTC)
Thanks for attacking this long-standing problem! --Tordanik 14:04, 14 February 2021 (UTC)
PluggableAuth may not be sufficient to address the issue, at it is only a framework to create authentication and authorization extensions on top of it. Also, OAuth2 authentication isn't available yet on the Rails port ( website), which means we cannot use plugins like OpenID Connect. Then, having an explicit link between the Wiki and (vs. an implicit one which relies on the same username across both sites) is the preferred option. Matching via username and email also wouldn't work, because we deliberately don't expose users' email addresses via any API call for privacy reasons. There's quite a bit of work involved here which goes much beyond installing a Wiki plugin. mmd (talk) 11:40, 21 February 2021 (UTC)
@Mmd: What would you suggest be the steps we should take to making this happen then? How exactly could we establish an explicit link? --Lectrician1 (talk) 07:22, 22 February 2021 (UTC)
Well, finding that out would be exactly one of the tasks of the Github issue. We probably need some Mediawiki expert and/or more research to work out possible solutions. Think of the whole topic more in terms of a project, rather than some few hour configuration task. Mmd (talk) 09:36, 22 February 2021 (UTC)
Ok, I was wrong, for the demo in to work, it took a few hours only (mostly to install a Mediawiki instance and all required extensions). For production quality some more work would be needed, of course. Mmd (talk) 09:52, 11 August 2022 (UTC)
Hm ... the goal discussed in some previous conversations, and when writing that Top Ten Tasks entry, was to eventually get rid of the distinction between OSM wiki account and OSM account as far as practically possible – i.e. users would have the same name, and there would be no need (and no ability) to "create a wiki account". How would the process of establishing an explicit link look for an OSM user editing the wiki for the first time? --Tordanik 19:29, 26 February 2021 (UTC)
@Tordanik: They could sign in with and their account would be created based on the information returned by the OAuth client. This would work exactly the same as when you login/signup with Google on a site and you are able to immedeatly use it. --Lectrician1 (talk) 02:23, 27 February 2021 (UTC)

It seems that further activity would be at - and that is solved as far as we can here, right? Mateusz Konieczny (talk) 10:13, 19 March 2021 (UTC)

Maybe create Authentication from describing the situation? Mateusz Konieczny (talk) 11:08, 6 March 2022 (UTC)
There is Develop/Single sign on. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 12:08, 3 April 2022 (UTC)
This seemed fairly outdated. I removed all of the content which is no longer relevant (which is close to blanking the page). Mmd (talk) 09:54, 11 August 2022 (UTC)
SotM 2022 presentation Running - Today and Tomorrow by Grant Slater mentions Wiki single sign on on slide 12. Mmd (talk) 18:49, 13 September 2022 (UTC)

Add Page Forms Extension

Page Forms allows users to create forms who's inputted information can then be formatted and inserted into a page.

I would like to use Page Forms to create forms that allow for the easy creation of proposal pages and the management of transitioning proposal stages.

For example, a Page Form could allow:

  • Each of the proposed tags and their used entities, descriptions, and examples to all be easily-inputable and displayed in a standard fashion.
  • Proposal can change stages from draft to proposed to voting to post-vote, all with the configuration of the form. This requires no editing of the proposal itself.
  • Possibly the seamless transition from copying a proposal's data from the proposal to a new page(s) for the approved tags.

Here are examples of sites that use Page Forms.

--Lectrician1 (talk) 00:41, 9 February 2021 (UTC)

"Proposal can change stages from draft to proposed to voting to post-vote, all with the configuration of the form. This requires no editing of the proposal itself." - how it would be detected?
"easily-inputable and displayed in a standard fashion" - how it deals with fact that proposal may propose one new key or new value or values or deprecate existing tag or change voting rules or introduce new key and deprecate specific value (or values) and so on? Mateusz Konieczny (talk) 07:54, 17 February 2021 (UTC)
  • @Lectrician1: - have you tested how this extension interacts with all subsets of extensions that you also proposed? And with current OSM Wiki install? Mateusz Konieczny (talk) 10:44, 23 February 2021 (UTC)
    • @Mateusz Konieczny: I'm going to setup my own install of MediaWiki and test before I suggest we move forward with actually implementing it.
      Also for, "How would it be detected". What I mean is that with Page Forms none of the raw text on the proposal has to be edited. Everything is configured through the form. Selecting an option for a proposal stage in the form should be able to automatically add the voting section to the proposal, etc.
      Form elements are also replicatable so you can setup a field to repeat itself with multiple options. For example, you can add as many tags that you want to propose addding or depreciating etc. IDK if this makes sense :P
      --Lectrician1 (talk) 16:22, 23 February 2021 (UTC)

Template:Languages/div Mediawiki bug


I can't open Template:Languages/div. There is no page at all, only the name of an error and date. This is the first time I've seen such a bug. maro21 22:31, 26 April 2021 (UTC)

The same for me:
[ecf673d83453ac48a248f2fa] 2021-05-03 23:11:13: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
--Vazhnov Alexey (talk) 23:15, 3 May 2021 (UTC)
Reported openstreetmap/operations/issues/533 --Tigerfell This user is member of the wiki team of OSM (Let's talk) 17:14, 14 May 2021 (UTC)
The reply suggests that there is an issue with that wiki page. Since I do not even know what the template does I will not change it. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:59, 16 May 2021 (UTC)
As Template:Languages/div and Template:LanguageLink are no longer used since Minh rewrote Template:Languages and the wiki has never had any pages in Marathi the only real concern is what the underlying problem is. Has this been reported on the Mediawiki bug tracker? --Andrew (talk) 15:44, 16 May 2021 (UTC)
I can only speculate that the lack of any Marathi pages on the wiki might have triggered the error. Since I removed this language, the database error no longer occurs. Mmd (talk) 17:00, 16 May 2021 (UTC)
Looks like there is something wrong with the Marathi language in {{Languagename}} template.
See for example
{{Languagename|de}} -> Deutsch
{{Languagename|abc}} -> abc
but {{Languagename|mr}} throws an error
This template uses magic word #language but {{#language:mr}} works well.
{{#language:ar}} -> العربية
{{#language:br}} -> brezhoneg
{{#language:mr}} -> मराठी
I'm still thinking how to solve it. maro21 16:57, 18 May 2021 (UTC)
The {{Languagename}} template was used enthusiastically by, and over-engineered by, a former wiki contributor for purposes such as enabling links to Wikipedias in languages without Mediawiki support. Many (not all) uses can be (and often have been) replaced with #language; {{Languages/div}} needed it for gcf: until the current language template made it redundant. --Andrew (talk) 19:48, 18 May 2021 (UTC)
We could revisit the remaining templates with languagename and convert as many as possible to #language. --Andrew (talk) 05:50, 20 May 2021 (UTC)
I didn't say that we should get rid of the template:). There was a problem only with Marathi language but this language isn't used on this Wiki at all. I think there is a bug with the database somewhere, the template is ok. maro21 19:28, 20 May 2021 (UTC)
Wiki:Babel templates was also affected through Template:Babel list of languages, fixed by replacing Languagename with #language. --Andrew (talk) 11:40, 20 May 2021 (UTC)
I think I’ve found the problem. {{#language:mr}} (Marathi, native name) works correctly. {{Languagename|mr}} expands to {{#language:mr|mr}} (Marathi, in Marathi), which doesn’t. {{#language:en|mr}} (English, in Marathi) also fails. There is no problem with {{#language:mr|en}} (Marathi, in English) so OsmAnd renders. Tagalog has the same problem ({{#language:tl|tl}} fails) and there may be others that we don’t refer to on this wiki. --Andrew (talk) 17:49, 23 May 2021 (UTC)
Good job! But where are these defined? Somewhere in the Mediawiki files? I've never seen source code of Mediawiki and I don't even know where to look for. I checked your examples on English Wikipedia and they work well. maro21 18:07, 23 May 2021 (UTC) --Andrew (talk) 19:02, 23 May 2021 (UTC)

The same bug here: File:K9 BountyHunter.png and File:Wetter Atlantiksturm.png. maro21 21:47, 14 June 2021 (UTC)

Not sure if it's related, but I'm seeing this issue with a creative but valid invocation of {{Tag}}: Template talk:Tag#Database error with HTML character entity reference to emoji. – Minh Nguyễn 💬 02:00, 1 December 2021 (UTC)

I can't open Key:tracktype nor any other language version: Item:Q784. The bug must be somewhere in the data item because {{KeyDescription|key=tracktype}} itself generates an error. maro21 20:32, 2 January 2022 (UTC)

This is a broader problem than I thought: No tag or key page that has a description in Hebrew can be opened, see:
But it's not this user's fault, because not long ago I was accessing some of these pages and everything was working. Have there been any recent MediaWiki updates? Because sorting by namespace in Recent Changes doesn't work either. maro21 21:01, 2 January 2022 (UTC)

I can open all of those: I don′t see descriptions in Hebrew by default but I get them if I view all languages. I can also view He:Key:fax and fax (Q268). --Andrew (talk) 13:41, 3 January 2022 (UTC)

Legal requirements to images or media files

> Main topic: Category:Media without a license

Several uploads to the Wiki still have been done without specifying the license and many images are in use missing an adequate license.

On search how to put things better I looked for a guide or at least an annotation, what has to be respected with uploading and using media like images in the Wiki. But I cannot find such!

  • There is one short and unclear note at Wiki_Help. And that page not even is linked at mainpage or main help page Get_help. (Another issue itself.)
  • Even at the Special:Upload page there are several hints but there is no given help what licenses must or can used basically.

IMHO that way we cannot expect "correct" use of media in the Wiki. I myself have my difficulties with seeing what is right now in view of (using) uploads.

I think an upload or media guideline must be created and put at Wiki_guidelines. And the Wiki guidelines must be directly linked at Get_help and at Special:Upload.

Question: Did I miss or overlook a description or guide in terms of licenses with images at the Wiki and can anyone provide a link?

I would really appreciate if more users could help hereby. --Regards, Chris2map (talk) 19:08, 1 November 2021 (UTC)

At Special:Upload you first see MediaWiki:Uploadtext, at least if you see this page in English, German, or Spanish. It mostly focuses on the question whether the uploaded files are relevant to this wiki not so much on licensing. The upload page also features a dropdown menu for selecting the correct license. This is taken from the configuration page MediaWiki:Licenses. Licenses in this list are definitely acceptable. Media license templates lists all licenses I know. I guess the problem with GFDL is that you are not allowed to trace from such files for OSM. I do not know why it should be a problem to upload such files.
Some sort of guideline could be useful.
I currently do not fix the licensing issue because there are still the options to select "None selected" and "I don't know exactly" which leaves it up to others to fix the licensing. This is often more difficult because you have to find out if the uploader took the picture by themselves etc. Just looking at the last ten uploads (until 19:15, 2 November 2021 UTC) you find four without any licensing and one with a contradicting licensing combination. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 23:02, 2 November 2021 (UTC)
By the way, this topic also came up recently in relation to a claim of fair use, which is of questionable applicability to a website based in the United Kingdom or European Union. We should at least do something about Category:Labelled for deletion, but Category:Media without a license needs a lot of work to contact the uploaders for more information (giving them a fixed amount of time to respond before deletion, that sort of thing). – Minh Nguyễn 💬 01:43, 3 November 2021 (UTC)
Deciding whether we can and should keep fair use images is one of things that needs to be done Mateusz Konieczny (talk) 09:55, 3 November 2021 (UTC)
Category:Labelled for deletion can be emptied only be people with admin rights and they do it, though quite slowly (but there is no real backlog here) Mateusz Konieczny (talk) 09:55, 3 November 2021 (UTC)
Category:Media without a license - what you think about splitting it into subcategories "uploader not notified" and "uploader notified", with second split based on notification date? This would make easier to ensure that all editors are notified and later to start deleting images where uploaders were notified and failed to respond for a long time. Right now processing this category is irritating as many images are stuck in limbo, without any action to be taken for now Mateusz Konieczny (talk)
That could work, though it's even more manual work. Wikipedia and Commons actually use a bot to handle these notifications. Smaller Wikipedias don't run bots for them, but most wikis have a template similar to {{Unknown}} that automatically adds the page to a category based on whether it's been tagged for more than a week (or some other time period). That kind of automation requires using the subst: keyword when inserting the template. – Minh Nguyễn 💬 17:56, 3 November 2021 (UTC)
I actually have plans to automate this a bit - but I want to design process before sending thousands of notifications, also it would be nice to have it runnable without relying on bots (even if it would be more tedious). And yes, something subst: based would be included Mateusz Konieczny (talk) 11:50, 4 November 2021 (UTC)
Thanks for your replies! The ideas to straighten or establish a process to handle the license issue sound good. The template to categorize the contacted cases might automatically switch from "uploader notified" to "uploader notified without reaction" after 4 weeks since placing the template (if this works). - The other part, an explanation for normal users what are the requirements, should been made available as quick as possible. Last week I contacted a user who recently uploaded loads of images and he will/might subsequently add source (own pictures) and license information. He didn't complain, but understandably will not be delighted to edit dozens of file pages. - Is there anywhere a kind of document that can provide a basis for the explanation? --Chris2map (talk) 20:41, 4 November 2021 (UTC)
Talk:Wiki#PD-shape_to_series_of_images is related topic where help would be welcome and basically anyone can do this Mateusz Konieczny (talk) 15:31, 27 November 2021 (UTC)
I linked Wiki Help at Get Help Mateusz Konieczny (talk) 13:07, 8 December 2021 (UTC)
  • Addition to MediaWiki:Uploadtext
Please have a look at MediaWiki_talk:Uploadtext#Addition_of_two_basic_statements. I'm proposing two basic statements for the file upload page. --Chris2map (talk) 16:38, 28 December 2021 (UTC)


MediaWiki:Uploadtext - Addition of basic statement

(Follow-up of discussion from MediaWiki_talk:Uploadtext#Addition of two basic statements)

-- (copy of last 3 comments) --
I see your points. Let's try a conclusion:
I . Please do not upload any file without clarifying and indicating the source!
II . a) If you are the author of this file, you must make it available under a free license.
b) If you are not the author of the file, the file must be under a free license and you must provide the source.
c) In any other case you have to clarify the legal use and compatibility with OpenStreetMap Wiki. A file without source and license will be deleted later.
(The linked pages would still have to be created.) What do you think? Please check my wording. --Chris2map (talk) 12:41, 29 December 2021 (UTC)
Technically, seems to trend toward allowing at least some unfree images. But maybe it is not necessary to mention it in summary, just link to full version somewhere? But it would be nice to clarify upload text before we handle fair use and have some clear policy on that. Mateusz Konieczny (talk) 13:18, 29 December 2021 (UTC)
I suggest we continue the discussion in the linked thread on Talk:Wiki given the general impact with regards to file uploads. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:24, 30 December 2021 (UTC)
-- (end of copy) --

I hope we can get to a simple conclusion without clarifying all parts of licensing and a quick implementation of the statement on file upload page. --Chris2map (talk) 12:59, 31 December 2021 (UTC)

I thought it would be more useful to establish the licensing guideline first and then change MediaWiki:Uploadtext and all of its translations accordingly. Otherwise, we would need to change it multiple times. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:08, 31 December 2021 (UTC)
I definitely have to agree with you on the need of a comprehensive guideline and that file upload page should be changed as few as possible. However, the statement "I." of above is matching the common state and appropriate without further guidelining, IMHO. I would like to bring this forward. --Chris2map (talk) 08:57, 2 January 2022 (UTC)

Guidelining chart for media file licensing

I want to put my draft for a chart up for discussion: Drafts/Media file license chart --Chris2map (talk) 10:36, 2 January 2022 (UTC)

Thank you for that! Maybe asking LWG for review could be useful? Mateusz Konieczny (talk) 08:03, 6 January 2022 (UTC)
Yes, at least we could ask. Per which way? legal-talk mailing list? - Should we go soon or first turn another round in wiki and try to get more feedback from team or contributors? This was my intention. --Chris2map (talk) 12:31, 6 January 2022 (UTC)
It would be nice to get more feedback before taking any further steps of survey and proposing. I don't want to rush ;) --Chris2map (talk) 15:02, 6 January 2022 (UTC)

Beside the chart to help what to do with uploading regarding licensing, we need to help how to do it (technical/practical), don't we? E.g. where and how to edit, how to embed license, layout things (like header), etc. I think that should be provided on another page (a manual / step-by-step instruction) and not on the chart's page. What do you think? --Chris2map (talk) 17:12, 15 January 2022 (UTC)

Designing policy for handling files without clear license

OSM Wiki has a serious problem with files that have no clear copyright status ([4][5]).

We have many files that are blatant copyright violations.

Many wiki pages is using clear known copyright violations or files with unknown status.

There are following groups

  1. Clear copyright violations - obvious copyright violation, also files where uploader admitted that files are copied from random website, Google Street View or source is stated. Or files copied from Wikimedia Commons that were deleted there.
    • Such files should be identified and marked with {{Delete}} template
  2. Files openly licensed and marked as such with proper licensing template, with clear source
    • Not a problem
  3. Files where licensing info is stated, but in text rather than using a proper licensing template
    • In such case licensing template should be applied
  4. Files where licensing info is missing and author was never notified about problem
  5. Files that were clearly uploaded in good faith by OSM mappers, but without any licensing info and uploader is inactive
    1. What should be done with such files? Delete? Keep and mark specially?
  6. Fair use - unfree images that re impossible to replace and important

Why this cleanup is worth doing?

  • Copyright violations are illegal and often unethical
  • Files with unknown copyright status have limited usability and are a legal risk
  • Reputation of ignoring copyright is unwanted for us
  • OSM Wiki content, including images, should be safe to use and usable by others - not filled with traps
  • Nearly all problematic images are replaceable by superior images


  1. How long we should wait between notifying uploader and deleting the image? 2 months? 4 months? 1 month?
  2. Is it desirable to delete old irreplaceable images with unclear licensing status uploaded by OSM mappers? For example photos of OSM events?
    1. If such images would be kept - how to specify rules to block further uploads without a clear status?
  3. Is it OK and desirable to have some fair use images? On which rules?
  4. Have I missed some category of images?
  5. Is it OK to upload "noncommercial use only images"? This is problematic as it is not really clear which use is forbidden, severely restricts reusability and so on. Wikimedia Commons is not allowing such images for quite good reasons
  6. Would it be OK to allow user-page only personal images that are not openly licensed? See User_talk:Nacktiv
  7. Template:Maxar image - Are we allowed to use Maxar imagery such as for illustration on wiki? If yes - why and how? (it is not covered by editing permission - "you understand and agree that you may only use our imagery to trace, and validate edits that must be contributed back to OSM. You cannot download our imagery or use our imagery for any other purpose" - Maxar
  8. Template:Bing image - Are we allowed to use Bing imagery for illustration on wiki? If yes - why and how? (it is not covered by editing permission - "The rights that you have under this agreement are limited solely to aerial imagery use in a non-commercial online editor application of OpenStreetMap maps (an "Application")." - Bing Maps) Mateusz Konieczny (talk) 02:36, 9 December 2021 (UTC)
  9. Should we allow CC-BY-NC-ND / CC-BY-NC / CC-BY-ND media at OSM Wiki? Mateusz Konieczny (talk) 22:43, 1 August 2022 (UTC)
At first reflex I thought no. But then I thought about where a problem would arise in that. The wiki is not a commercial project, so using these licenses would be OK. Also, if there is a link to a wiki page from other websites or services. I think normally a wiki page and the images it contains are not reused, but only linked or reproduced. - However, the first problem is when someone does reuse wiki content in such a way that it becomes part of a commercial service. We can't control that. The second problem is that images not only appear on wiki pages, but can also flow into databases, e.g. via taginfo or in the data items. Then commercial use is very likely. And how do we want to regulate and control this, so that in some cases the license is OK, but not in others. I can't imagine how this is supposed to work in practice. The mixing, if we allow the -NC and -ND licenses, is unavoidable. So in the end I would say that we should avoid these license variants. --Chris2map (talk) 20:26, 2 August 2022 (UTC)
The worst part for me is that "commercial" is not really clear. Lets say I am making an OSM editor and got grant supporting its creation. Can I use such images? Mateusz Konieczny (talk) 06:38, 3 August 2022 (UTC)

Extra questions (added later)

  1. How much of imagery is allowed? Is small snippet of unknown imagery like at allowed? Mateusz Konieczny (talk) 15:24, 4 March 2022 (UTC)
  2. What about licenses which allow commercial use with exclusions such as (less radical than Wikimedia Commons, but sadly necessary if one cares about blocking bad-faith parasites like Getty Images at cost of harming some legitimate reusers). Example: Mateusz Konieczny (talk) 04:41, 15 June 2022 (UTC)


Please, if you have any opinions on questions raised here - please comment. Mateusz Konieczny (talk) 02:36, 9 December 2021 (UTC)

"Keep and mark specially" should be the policy for all files without a license right now. We can't expect to go through all of them and we shouldn't delete them either since we can expect most of their uploaders to not be active and many are useful to have. Lectrician1 (talk) 15:35, 3 June 2022 (UTC)

Example where it is not entirely clear who is the author: - this file is from Commons:
Re questions:
1 - I would say 6 months. But we can also try to contact them on because it's more likely they will read the message there if they haven't been logging in to the Wiki for a long time. But 6 months for old files, uploaded long time ago and where the user is not active.
2 - I wouldn't delete them.
3 - Yes, if there is a need, as in the examples you gave. maro21 22:57, 9 December 2021 (UTC)

@Maro21: "6 months" That is for old images, right? What about brand new upload where user was notified within days from upload? Would it be OK to have shorter time there? Mateusz Konieczny (talk) 08:14, 10 December 2021 (UTC)
I assume that in such cases they will react, answer and add a license sooner than later ;p. Otherwise yes, shorter time would be ok, 1 month? maro21 16:45, 11 December 2021 (UTC)
IMHO 3 months for old ones is OK, but I'm also fine with 6 months. For new ones, if uploader is notified in same week (within 1 week) then 1 week time limit from moment of notifying should be adequate. If within 2 weeks then +2 weeks. Within 1 month then 1 month. - What about this proposal: If image file is uploaded without selecting a license, there will be automatically added a template that indicates there is no license and sets a time limit (e.g. 2 weeks) for deleting the file? --Chris2map (talk) 19:16, 11 December 2021 (UTC)
@Maro21: "I assume that in such cases they will react, answer and add a license sooner than later" - at least some are no longer active, sometimes for 10 years and more. We have large enough project that some left completely (sometimes due to lack of further interest, some were banned and some died) Mateusz Konieczny (talk) 08:08, 12 December 2021 (UTC)
I meant recent uploads from active users, that they will react sooner so 6 months period won't be necessary. maro21 21:56, 12 December 2021 (UTC)
3 - Are screenshots of websites such fair use images as long as they are used as previews in descriptions or lists of the website service and the service relates to OSM in some way? (e.g. List of OSM-based services) --Chris2map (talk) 19:02, 28 December 2021 (UTC)

7 - (Use of images of Maxar imagery) In most cases images are used in the wiki to describe or support the tracing or validation process. Might this be interpreted as part of validation? --Chris2map (talk) 13:50, 28 December 2021 (UTC)

Good point, maybe it would work with broad interpretation Mateusz Konieczny (talk) 14:14, 28 December 2021 (UTC)

2.1 - (how to specify rules to block further uploads without a clear status) Wikimedia Commons uses abuse filters (like #31, #154, #156). There is also an abuse filter preventing the upload of files without a license. This solution avoids that administrators have to review the obvious cases of copyright violations. Otherwise, I expect a lot more deletion requests coming up. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:29, 31 December 2021 (UTC)

Extra question 2 - this file can stay since it was first posted to Pixabay prior to 9 January 2019, when they changed from a Creative Commons Zero license to a license that allows commercial reuse with some restrictions (refer to commons:Template:Pixabay). Same principle applies for files originally from Pexels (before 4 July 2018) and Unsplash (before 5 June 2017). Can't say the same for files that were first posted in Pixabay/Pexels/Unsplash after their respective cutoff dates. -Ianlopez1115 (talk) 12:46, 17 June 2022 (UTC)

It is worse! "this file can stay since it was first posted to Pixabay prior to 9 January 2019" - but it was uploaded to OSM Wiki after that, so it was almost certainly obtained on restrictive license (it does not matter that it was earlier available on more permissive one, though maybe getting it from internet archive page of old versions is still possible?) Mateusz Konieczny (talk) 16:00, 17 June 2022 (UTC)
Could that serve as an alternative source ? The website itself carries "(c)2016" in footer. They state that they couldn't guarantee for the permission, but who can? (Can we be sure in every case on Commons?) --Chris2map (talk) 17:15, 17 June 2022 (UTC)

copyright violations that need replacement

I would really appreciate help with removing copyright violations. Files were not reviewed for a long time and there is a noticable backlog. We really should not use images illegally - it is problematic for several reasons. (resurrecting as I keep finding such file at rate greater than I can process) Mateusz Konieczny (talk) 18:06, 12 December 2021 (UTC)

Generally editable part

Help is needed with handling some illustrations that turned out to be a copyright violations.

You can help by following:

  • open file page of one of files below
  • Go to "File usage" section and open page or pages listed there
  • Replace it with some alternative (preferable) or remove it
    • Note that proposed alternative images are listed at given file pages
  • Save page with edit like "remove copyright violation"

Once file is not used anymore

  • replace {{Delete proposal}} by {{Delete|Unused copyright violation, see file talk page for details}} to let wiki sysops that file should be deleted
  • mark such file as processed by removing it from the list below


For files without replacement:

  • Find acceptable (or better!) image on Wikimedia Commons
    • Or upload file on a free license to Wikimedia Commons / OSM Wiki
    • You can take image on your own and release it under open license
  • Edit file page with note where such image is
    • Or immediately do steps listed above
  • Edit list below and remove this file

If image use is unimportant or impossible to replace - then just remove image.

Mateusz Konieczny (talk) 18:06, 12 December 2021 (UTC)

Dubious licensing of a derivative work

I started asking users to state license of work they uploaded. In most cases it was just clarification of self-made work but there are cases where it is not obvious and appears that users tag things as "own work" where it is actually just screeshot and they may not hold copyright. In such cases user should be asked a clarifying question.

I already edited what I post on user talk pages to be more clear and to be better at not triggering such answers.

I plan on handling that but I post here in case that something would go wrong with that to prevent likely invalid license staying.

If anyone want to handle one of such case: feel free to ask this users. If something is fully explained - feel free to edit list above.

In case of solving something from this list: please add note on the list below Mateusz Konieczny (talk) 11:13, 31 January 2022 (UTC)

Current list is as follows:


  • File:Beverley.png, File:Trieste 2009.01.13.png - these are Osmarender screenshots, so for sure it's not CC0, I changed it to {CC-BY-SA-2.0 OpenStreetMap} + [Category:Osmarender Rendering Examples]
  • File:R kleineisel 6.png - if the map data comes from OSM, it should also have at least {CC-BY-SA-2.0 OpenStreetMap}
  • File:Bahndach.jpg - screenshot of Potlatch should have the same license as the program?
  • File:BusStopConnection.png - an iD screenshot, so I added the license. Not enough features to say it's either "copyright OSM contributors" I think. maro21 23:23, 29 March 2022 (UTC)
  • File:Balticmaps-high zoom.png - as I can see on the data does not come from OSM, so it's copyrighted and may not be on a free license. maro21 23:42, 29 March 2022 (UTC)

Forbidding upload of new files using outdated Creative Commons license?

Related to Talk:Wiki#Designing_policy_for_handling_files_without_clear_license

See for description of the problem.

I propose to follow their recommendations and to

  • forbid uploads of new files on this affected licenses
  • Modify license templates and note the problem
  • Notify uploaders of this files and ask them to consider relicensing

Mateusz Konieczny (talk) 17:59, 25 February 2022 (UTC)

Thanks for discovering! I think we should regard that. At least prohibit uploads and enhance the templates. --Chris2map (talk) 20:25, 14 March 2022 (UTC)
What about this text for the "-self" templates? Dear author! This version of the CC license is outdated. Please consider updating to latest version 4.0 to avoid legal hassle. (Learn more). Maybe we should create a wiki page with infos and link to it. --Chris2map (talk) 21:35, 14 March 2022 (UTC)
I agree with you, I think that users should be encouraged more clearly to indicate the license of the imports properly. But I would be in favor of giving them a minimum time to react (like 1-2 weeks) — Koreller (talk) 06:40, 25 May 2022 (UTC)
Regarding the technical side, I have not found a mechanism to implement this using abuse filters. Just wanted to let you know ... --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:38, 3 August 2022 (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 — Koreller (talk) 09:14, 23 March 2022 (UTC)

Can you give examples of specific files and actions where it would be helpful?
I think that smarter solution would be moving files to Mediawiki Commons, we are unable to handle existing ones. Note that downloading, viewing files is possible already Mateusz Konieczny (talk) 11:22, 23 March 2022 (UTC)
@Mateusz Konieczny: The Media Viewer is orthogonal to where the images are hosted. It works just as well with images hosted on Commons. The interface looks a little different for such images, as you can see when previewing most images on Wikipedia. – Minh Nguyễn 💬 21:06, 14 April 2022 (UTC)
Once this extension is installed, will it be possible for anyone to disable it? maro21 18:59, 23 March 2022 (UTC)
@Maro21 Yes, you just click the settings button in the upper right of the image viewer when an image is shown and click "disable". Lectrician1 (talk) 22:22, 23 March 2022 (UTC)
Symbol support vote.svg Support Lectrician1 (talk) 22:23, 23 March 2022 (UTC)

mw:Extension:MultimediaViewer comes with MediaWiki these days. It just needs to be enabled. However, I'm pretty sure it depends on Beta Features and won't work unless that extension is also installed. – Minh Nguyễn 💬 21:06, 14 April 2022 (UTC)

Flags and separators in osm calendar

I believe the OSM calendar on the wiki frontpage, which is now managed as an external dependency (prior it was a wiki table), has lost some of its clarity by removing the flags and horizontal separator lines from the table. Before you could see on a glimpse where the events took place, now you are looking at a wall of text and have to read everything in order to see where things will happen. I have raised an issue with the developers, who have asked me to post a note here, in order to find out what others think and to keep track. See here for the original issue on github: --Dieterdreist (talk) 08:08, 20 April 2022 (UTC)

@Dieterdreist: I agree, some kind of visual indication or filter on the main page would make the global event listing more usable. In the meantime, individual country pages can embed filtered OSMCal listings, for example United States#Upcoming events. Hope this helps! – Minh Nguyễn 💬 20:21, 7 May 2022 (UTC)
I also preferred the old visual presentation and agree that the current "wall of text" is not ideal. To me, issues include:
  • The lack of structure/whitespace
  • No flags (which are useful because they let me visually scan a list for events that have a good chance to be near me and held in a language I understand)
  • Poor-quality automatic generation of place descriptions. A human would not have written "Berlin, Berlin, Germany" or included a city for an event that happens online.
  • Too much text (caused by unabbreviated names of months, country names instead of flags, and the automatic place descriptions)
--Tordanik 15:00, 10 May 2022 (UTC)
One of the challenges here is that the formatting is exclusively managed in an external dependency without much options to influence it using Wiki templating or Lua code. Extensions like provide much better options to customize external data presentation in a wiki. As it's a stable extension, it would also be one less of a dependency to maintain on our own. Mmd (talk) 13:47, 3 June 2022 (UTC)
I think it shouldn't be too much effort to replace the OSMCalWidget by the External Data extension, and move all styling to the Lua code for everyone to adjust as needed. I've uploaded some proof of concept code here, along with the Lua code, a Wiki page, and a screenshot: ... Let's bring the power back to the Wiki users. Mmd (talk) 18:09, 12 August 2022 (UTC)

Updating the wiki's license

According to the article, A Bug in Early Creative Commons Licenses Has Enabled a New Breed of Superpredator, early CC licenses, such as CC Attribution 2.0, which have very strict attribution requirement, where any mistakes being made, such as unintentional misspelling of names or some other details, will not be forgiven, and reusers are offered no chance in correcting their mistakes. Some copyright trolls (or rather, copyleft trolls) are exploiting this rule, to make people reusing CC-BY 2.0 works to pay for large profit for violating the license term, despite the original intention of creative common being such that people should be able to reuse others work freely.

And the OpenStreetMap Wiki's current license, is exactly "Creative Commons Attribution-ShareAlike 2.0", something affected by this. To mitigate such problem, Creative Commons as in the organization behind the license, have published an official blog, Do not feed the trolls, urging people to update their license to version number 4.0 in order to avoid problems caused by legacy license.

As such, I think OSM Wiki should also update the CC license accordingly to avoid random people uploading content onto this wiki site and try to use it as a way to extort profits out of the hand of others who use content on the wiki.C933103 (talk) 12:01, 22 May 2022 (UTC)

I support this change, I think our goal is not to create trouble for those who use the texts and images on the wiki, if they credit us properly. — Koreller (talk) 12:15, 22 May 2022 (UTC)
Support also from me. Thanks for addressing this! --Chris2map (talk) 20:36, 22 May 2022 (UTC)
Can we change OSM Wiki license without getting permission from all users who ever edited pages? (or deleting their contributions) Mateusz Konieczny (talk) 07:24, 23 May 2022 (UTC)
Yes I think that we have a legal issue, could OSM foundation help us to answer this question? (The question could also be: how did Wikipedia change its license?) — Koreller (talk) 15:58, 24 May 2022 (UTC)
GFDL license was modified to allow this - see Such action is extremely unlikely to be available to us. Mateusz Konieczny (talk) 16:46, 24 May 2022 (UTC)
@Mateusz Konieczny: That was the process for migrating Wikipedia's text from GFDL to CC BY-SA 3.0, which is far more complicated than upgrading from one version of a license to another. At the time of that migration, the Wikimedia Foundation made it a requirement to accept terms of use, which has two seemingly relevant provisions: agreeing that reusers may comply with the ShareAlike requirement by licensing their own work under "CC BY-SA 3.0 or later", and agreeing that "a hyperlink or URL is sufficient attribution under the Creative Commons license". These provisions apply only to text contributions, whereas image contributions can be uploaded under a variety of licenses. It seems that Wikimedia Commons image contributions are a vector for this kind of attack. – Minh Nguyễn 💬 08:26, 25 May 2022 (UTC)
You can contact LWG and I expect that answer will be "it is impossible". But we can migrate/exchange media files. If someone is interested they can try to help with this part Mateusz Konieczny (talk) 16:48, 24 May 2022 (UTC)
Because CC licenses have upgrade clauses, it seems quite possible to switch to 4.0 and would not require permission from existing users. --Tordanik 15:10, 25 May 2022 (UTC)
Oh right, I was unaware of this - "You may distribute, publicly display, publicly perform, or publicly digitally perform a Derivative Work only under the terms of this License, a later version of this License with the same License Elements as this License" Mateusz Konieczny (talk) 07:05, 26 May 2022 (UTC)
See - for CC-BY-SA 2.0 they state: "Your contributions to adaptations of BY-SA 2.0 or 2.5 materials may only be licensed under: * The license used for the original work, or a later version of that BY-SA license. * Ported versions of that BY-SA license, the same or later version as the licensed work." - So later versions like CC-BY-SA 4.0 should be fine, shouldn't they? --Chris2map (talk) 11:18, 26 May 2022 (UTC)
Is anyone interested in working on this? Or at least planning? Not sure is it worth keeping it on this page in the current state as it is (1) a very large project (2) not confirmed that there is a clear support for this Mateusz Konieczny (talk) 06:21, 2 September 2022 (UTC)

See for mailing list posting Mateusz Konieczny (talk) 03:20, 30 September 2022 (UTC)

I still support it but don't have stamina to push it. I think discussion should stay here or maybe move to Talk:Wiki content license and leave a link here. --Chris2map (talk) 16:05, 3 December 2022 (UTC)

Updating license of media files

See also proposal to ban uploading new images on such outdated licenses which is much easier to implement, also images are higher risk. See also this section with more actionable copyright actions about mislicensed images and see this section with blatant copyright issues affecting OSM Wiki Mateusz Konieczny (talk) 07:29, 23 May 2022 (UTC)
@Koreller: @C933103: @Chris2map: - note that it is much easier to achieve with images where individual files can be relicensed one by one - would you be interested in writing a text that can be send to all such uploaders? There should be some mention that it is not applicable to old works based on OSM data? If such text would exist I could use bit edit to send it to uploaders of CC-BY-SA-2.0 licensed work which is not marked as OSM-based Mateusz Konieczny (talk) 12:47, 25 May 2022 (UTC)

Uploading CC-BY files should require stating authorship

As reported by @AngocA: upload file is not asking for file authorship even if selected license (CC-BY-*) makes mandatory to state authorship. This should be fixed to stop new files from appearing in invalid copyright state Mateusz Konieczny (talk) 15:14, 5 June 2022 (UTC)

Though from what I see there seems to template present that has space for that info Mateusz Konieczny (talk) 15:23, 5 June 2022 (UTC)
On side of the license templates we could add a notice for uploader to add attribution, see test on User:Chris2map/Sandbox&oldid=2336777. Notice only shows up for logged-in users (as uploaders are). --Chris2map (talk) 16:48, 5 June 2022 (UTC)
Is there any possibility in the code of the Special:Upload page to insert the CC licenses in the Information template? Then we could fill the attribution automatically with the content provided with "Author" in the Information. I made a test version to the template Information on Template:Sandbox (Template:Sandbox&oldid=2339353) that could be do like this example (User:Chris2map/Sandbox&oldid=2339354). --Chris2map (talk) 18:40, 9 June 2022 (UTC)
Unfortunately, this does not work with the upload page. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:08, 11 June 2022 (UTC)
How about an abuse filter that would catch files with missing or incomplete licenses? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:08, 11 June 2022 (UTC)
@Tigerfell: that would be great! Sadly I have no idea at all how abuse filters work (and for now scripts I wrote allow me to process more images that I have time for, especially given that some of notified people have questions that need to be answered...) Mateusz Konieczny (talk) 21:38, 22 November 2022 (UTC)
Following extensive research and testing I now created filter 16. As I am not sure if it works as intended, it just tags uploads for now. Those edits should appear in --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:06, 3 December 2022 (UTC)
There is one file on the recent list (File:2022-12-17-mapping party Reezekne RTA.png). I added license - How do we get it cleared from the list? - (Once when the filter doesn't list the files but instead sends messages to the uploaders, the problem no longer occurs.) --Chris2map (talk) 11:05, 4 December 2022 (UTC)
You can remove the tag via the page history and the button Edit tags of selected revisions on the right. Abuse filters can show warnings or hinder users to do a certain action. I just want to start with marking such uploads so I can see if the filter is working as intended. The documentation is somewhat confusing to me. Later, I want to show a warning at least. I am considering a warning message and hindering users to upload files without licenses. That depends on how well the filter works and if you think that is more helpful than harmful. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 14:51, 4 December 2022 (UTC)

Special:Upload - "content in a file format which is better suited for the content" can be uploaded to Wikimedia Commons

"content in a file format which is better suited for the content (e.g. SVG instead of JPG for drawings or charts)" - can we move that out of "should be uploaded to OpenStreetMap wiki"? This type of file can be uploaded to Wikimedia Commons Mateusz Konieczny (talk) 15:25, 5 June 2022 (UTC)

File upload in page editors lacks information of copyright or license

Stuck: --Tigerfell This user is member of the wiki team of OSM (Let's talk) 11:07, 17 July 2022 (UTC)

There is a "inline" file upload method in VisualEditor, I wasn't aware until now. This way of file upload doesn't provide any information like author, copyright, license or source. There is a checkbox for a kind of standard licensing, but it doesn't seem to work. This needs to be fixed urgently! - I tried to gather some background information [6], [7], [8], but I didn't get any further. The linked help pages give the impression that the upload dialog in the VisualEditor uses the same settings as Special:Upload. Something is obviously not working here. (Maybe simply this "standard license" for the checkbox is missing somewhere.) - If it can't quickly be fixed, that upload dialog in VisualEditor should be deactivated in the short term, IMHO! Who could ckeck and fix this? --Chris2map (talk) 08:48, 26 June 2022 (UTC) Same upload dialog and issue appears with the standard text editor. --Chris2map (talk) 19:46, 27 June 2022 (UTC)

Thanks for pointing this out. I do not know how to solve this problem because Visual Editor is configured identically in all OSMF-hosted wikis. I would need to specify the licence template in the configuration. Those templates do not necessarily exist in the other wikis. So, fixing the issue in this wiki might break the functionality for another one. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 11:07, 17 July 2022 (UTC)
Hmm, do you know the place where this issue could be noted or addressed? Maybe it's possible to set a neutral named template that is only executed if existing in a wiki (and each wiki could put custom content in the template or not use it). Or maybe it's possible to have a parameter or variable that can be set in the wiki. - If this can't be implemented in short term, is there a way to sabotage the upload function in this wiki so it won't complete successfully and users have to use special:upload page? --Chris2map (talk) 19:29, 22 July 2022 (UTC)
Sorry for the late reply. The correct addressees are the Sysadmins via GitHub because this is where those settings are adjusted. The tricky thing is that the other wikis are either write-protected [9] or even read-protected [10][11] and I do not have access to any of them. So, I can not actually see what I am doing there when I propose a configuration change for all wikis. The last restructuring of the wikis' configuration files created a separate section of configuration for this wiki (location in the source code). I opened two PRs yesterday. If they merge them I can open another one and put the previously discussed code in there. I already created Abuse filter 16 which reminds users of missing licence templates and links to the media file license chart and I changed an interface message to point out that the users have to add the licence template themselves. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 15:07, 18 December 2022 (UTC)
See how it looks like for the user: Mateusz Konieczny (talk) 16:15, 14 November 2022 (UTC)

Documenting changeset tags separately from element tags

Changeset tags (Category:Changeset tags) are currently just documented on Key:* pages, which however is pretty confusing, since it conflates changeset tags and element tags in ways that are not immediately obvious. E.g. most of these tags have status=discardable but this of course refers to the usage on elements (since changeset tags in fact cannot be discarded since they're immutable). So e.g. the status of the created_by=* tag should probably actually be "de facto" for the changeset tag. Likewise the {{KeyDescription}} infobox shows the taginfo usage, which of course only refers to the usage on elements but that again is not immediately obvious.

So I think it would make sense to document the changeset tags in a dedicated namespace, perhaps as subpages, e.g:

Key:source, Key:created_by, Key:imagery_used would then only document the usage on elements (like 99% of Key:* pages do) and of course link to the respective changeset tags.

I think that this would clear up the documentation, what do you think? --Push-f (talk) 06:08, 20 July 2022 (UTC)

Maybe Changeset key:created_by or ChangesetKey:created_by instead of namespace that has own baggage would be better? Mateusz Konieczny (talk) 11:20, 20 July 2022 (UTC)
Yeah that would also work. In that case I'd prefer CamelCase. A small advantage of using subpages would be that they would automatically link to Changeset but I guess such a link could also be produced via a template. --Push-f (talk) 04:57, 21 July 2022 (UTC)
On a related note I think we should deprecate use on changesets (P37) and instead introduce data items "changeset key" and "changeset tag" to be used with "instance of". --Push-f (talk) 11:23, 1 August 2022 (UTC)

Install the WikibaseCirrusSearch extension

I'd like to propose installing the WikibaseCirrusSearch extension, which extends the existing search engine with a few search operators that would be very useful for managing and finding data items. Here are some examples, along with corresponding SPARQL queries:

Sophox can already perform such queries and more, but not everyone is comfortable learning SPARQL. Even as someone well-versed in SPARQL, it takes me a while to figure out how to express simple queries like the ones above. As with the search operators built into the existing CirrusSearch extension, WikibaseCirrusSearch operators would be exposed through the MediaWiki API's existing query action, giving editors and data consumers more flexibility in querying the wiki's structured data.

The proposed extension would not affect the presence or prominence of data items in any way besides making it easier to search for them. I figure that if we're going to have Wikibase here, we might as well have the bits that make it usable like it is on Wikidata. If folks here are receptive to the idea, I can open an issue in the operations repository requesting the extension. Of course, it would be subject to the sysadmins' judgment about technical feasibility, but at a glance it seems like a relatively lightweight extension.

 – Minh Nguyễn 💬 22:42, 26 July 2022 (UTC)

I have just my traditional worry that already existing parts are not working well and that adding piles of extension will make this wiki even worse frankenstein Mateusz Konieczny (talk) 04:43, 27 July 2022 (UTC)
I strongly support. Do it. maro21 20:42, 19 April 2023 (UTC)

Is having a list of tags for each coastal community a good idea?

See Veneto/Lagune e zone umide/Laguna di Venezia and Talk:Veneto/Lagune e zone umide/Laguna di Venezia - maybe replacing this tables by links to more generic listing would be a good idea? Mateusz Konieczny (talk) 13:07, 1 August 2022 (UTC)

This is an article from the prehistoric times, when there may not have been what we have now. I haven't read into it and analyzed it, but I think that instead of deleting it, it would be a good solution to move it to user space. Or leave it. Or marked it as not up to date. maro21 20:44, 19 April 2023 (UTC)

new proposal namespace

Due to some random quirk in history, there is now a proposal namespace in this wiki. I would suggest to move the proposals there and update pages like Proposal process and Wiki organisation accordingly. What do you think? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:46, 3 August 2022 (UTC)

What would be changed as the result for viewers and editors? In addition to search hiding proposals by default (if I understand things right) Mateusz Konieczny (talk) 15:48, 3 August 2022 (UTC)
IMO proposals should show up in the search by default, so if we decide to move them to a new namespace we should IMO add it to $wgNamespacesToBeSearchedDefault. --Push-f (talk) 20:29, 3 August 2022 (UTC)

hiding proposals by default

That is not true! The search rank of pages in this namespace is slightly lower than the page rank of other namespaces. It means that if there are two pages with an identical relevance to a search term, the page in the proposal name space is shown underneath the other result. That namespace is searched by default. Additionally, one can use the advanced search to search the namespaces individually. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:55, 5 August 2022 (UTC)
Sorry, I got confused and they are searched from what I see, Mateusz Konieczny (talk) 11:01, 5 August 2022 (UTC)
What is "random quirk in history" supposed to mean? --Push-f (talk) 20:29, 3 August 2022 (UTC)
We had some issue. I requested a configuration change in October 2019 and then a technically enhanced one in March 2021 because other changes were made to the configuration in-between. I do not even recall the discussion back then. It is all linked in the first change request. The requests were not answered for years and now a number of requests has been answered within days. That is what I meant with "random quirk in history". --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:55, 5 August 2022 (UTC)
Ah ok, thanks for linking these pull requests. I just noticed that you made a small typo and submitted a PR to fix that: [13]. Until that typo is fixed we shouldn't move any more pages into the proposal namespace because with the config error the talk pages currently end up in the main namespaces when moving a page to the Proposal namespace. --Push-f (talk) 07:00, 8 August 2022 (UTC)
What would be changed as the result for viewers and editors if this would be applied? Mateusz Konieczny (talk) 11:02, 5 August 2022 (UTC)
You could exclude proposals from the search if you want to or search proposals specifically. You could also get an RSS feed just for edits to proposals. So you get more features. --Push-f (talk) 07:00, 8 August 2022 (UTC)
Sounds good to me. I like the prospect of the proposals ranking a bit lower, to avoid confusing users who don't have a good feel for how much authority an inactive proposal carries. Some of the things under Proposed features aren't about features at all, like Proposed features/remove link to Wikidata from infoboxes and Proposed features/Add Translate extension to Wiki. The Proposal: and Proposal talk: namespaces could also be a home for some of the discussions that currently take place here at Talk:Wiki, with ample room to discuss without bloating an already bloated page. – Minh Nguyễn 💬 08:37, 6 August 2022 (UTC)
+1. I particularily dislike the Talk:Wiki archival process which regularly breaks all the links to discussions. --Push-f (talk) 07:00, 8 August 2022 (UTC)
+2. --Adamant1 (talk) 20:49, 4 December 2022 (UTC)
@Tigerfell: what this change would mean in terms of actual actions to be taken? Mateusz Konieczny (talk) 12:56, 4 December 2022 (UTC)
I originally intended to move all proposals into the proposal namespace. I have not done this yet. It seems like there is no opposition, so I would continue to implement this using TigerfellBot. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 14:54, 4 December 2022 (UTC)

Files with copyright issues where uploader was notified over 6 months ago

I have a list of files where uploaders were notified long time ago and it is now time for further actions.

I would be thankful if others would help! Note that hopefully only in some cases marking image for deletion is needed, and even then it can be opportunity to replace it by a better image. Mateusz Konieczny (talk) 13:54, 4 August 2022 (UTC)

Isn't there also the option of tolerating images that are not available under an open license as long as we don't have a reason to suspect copyright violation and cannot easily replace the images? Today, someone mentioned on talk-de that photographs of historical OSM events were deleted because the uploader wasn't the photographer and was therefore not able to grant permission to use the image under an open license, even though permission to use the image on the OSM wiki had been obtained at the time, and that doesn't seem ideal. --Tordanik 12:32, 6 August 2022 (UTC)
See this discussion. The plan is to avoid deleting valuable irreplaceable images where it can be assumed that user licensed it like other OSM Wiki contributions. And images such as File:SotM2021 group photo of some participants version3.jpeg which are irreplaceable and were made in a good faith, even if not fully OK.
"even though permission to use the image on the OSM wiki had been obtained at the time, and that doesn't seem ideal" - in such case (if it can be assumed that author was aware that they permit also commercial use and so on) - uploader should respond about that and ideally note it on the file description.
Which specific image should be preserved but was deleted or marked as awaiting deletion? File:Osm owl 2010-09-27 P9276171.JPG was linked but it fits neither description
What can be done and would be helpful
  • Process own files and if someone is the author - apply clear license (to make them actually reusable, note that images with unclear licenses are far less useful and may be deleted in future when different decision will be taken or needed due to legal situation)
  • Review files on this list and User:Mateusz Konieczny/friendly and this category - overall over 25 000 files await processing.
  • Consult someone whether we actually can knowingly keep files where people are likely to be unaware about license or uploading random files found on the internet, but it is not blatantly obvious (LWG?) - note that question whether we want to keep such files is separate
  • Review files marked as problematic and help with contacting their uploaders
  • Write template text for file which are kept despite lack of clear license
  • Create that template
  • Apply that template (mentioned in the previous step) where applicable and to nothing else
  • Help in reviewing what was done - I definitely made some mistakes. I spotted some of them when I was reviewing files which I marked 6 months ago as missing licences. For example one of files had license marked on the corner of image itself, so I now applied proper template instead of marking it for deletion. Tigerfell who is basically the sole moderator processing file deletions catches most of remaining ones, but likely not all.
  • Let me know how that message that I am adding on talk pages can be improved (without making it even longer and more complex)
  • Review of also can be useful if someone expects wrong files to be send for deletion
Participating in that discussion linked above also would be helpful
Help would be in general appreciated and is likely to result in better outcomes Mateusz Konieczny (talk) 13:44, 6 August 2022 (UTC) (@Tordanik:)

How one may create account while hit by "listed as an open proxy in the DNSBL"?

"Your IP address is listed as an open proxy in the DNSBL used by OpenStreetMap Wiki. You cannot create an account." -

What one may say to people affected by this? Can we waive such blocks? See

Mateusz Konieczny (talk) 22:31, 2 June 2022 (UTC)

Now that we have switched to hCaptcha it will be interesting to see how it affects spam user sign-ups. If it works well I would be willing to disable the DNSBL for a trial period. -- Firefishy (talk) 12:29, 5 August 2022 (UTC)
@Firefishy: "got blocked trying to reset my password on the wiki. whats this about? "Your IP address is listed as an open proxy in the DNSBL used by OpenStreetMap Wiki."" reported on Mateusz Konieczny (talk) 07:33, 8 August 2022 (UTC)
next victim at Mateusz Konieczny (talk) 20:54, 31 August 2022 (UTC)
Next victim at Mateusz Konieczny (talk) 17:35, 19 April 2023 (UTC)

Lua error in Module:Languages on talk: pages

I'm getting a Lua error message in the languages bar on pages in namespace "talk:"

Lua error in Module:Languages at line 62: attempt to index field '?' (a nil value).
1.  (tail call): ?
2.  Module:Languages:62: in function "translationPageName"
3.  Module:Languages:117: in function "languageList"
4.  Module:Languages:167: in function "chunk"
5.  mw.lua:525: ?
6.  (tail call): ?
7.  [C]: in function "xpcall"
8.  MWServer.lua:99: in function "handleCall"
9.  MWServer.lua:313: in function "dispatch"
10. MWServer.lua:52: in function "execute"
11. mw_main.lua:7: in main chunk
12. [C]: ?

E.g. on this page or on Talk:Map features. --Chris2map (talk) 19:38, 18 August 2022 (UTC)

@Chris2map: This wiki-wide error was caused by a series of edits to Module:Languages/config, which I've reverted for now.

Bgo eiu, I avoided fully protecting the page so that you can continue to make routine edits, but please don't ignore the constraints documented in the comments in that module; they're there for a reason. If you need to make non-routine changes to the module, such as making exceptions to those rules, please stage your changes in Module:Languages/config/sandbox, Module:Languages/sandbox, or Template:Languages/sandbox, or at least use the interactive console below the edit form to test your changes before saving. Thanks for understanding; I realize it isn't always obvious that a benign-looking list can have a far-reaching impact.

 – Minh Nguyễn 💬 05:21, 19 August 2022 (UTC)

Sorry about that, I saw the comment at the top about making updates to the names and didn't realize there was a way to cause this type of error from the module. (And was sort of confused on what the difference between "pseudo-namespace" and "namespace" implied - I was trying to make a change in the category name with out impacting the latter by referencing the "pseudo-namespace.") --Bgo eiu (talk) 15:36, 19 August 2022 (UTC)
Hopefully this won't break anything, but I will make a note here as well since in adding just the language codes to the list, I also updated the order. For any language using an Arabic/Persian based or Brahmic/Indic based writing system I went by ISO 15919 sort order rather than breaking up by script, because this allows the autonyms which start with the same sound to be together even if they use different scripts. So for example, Punjabi and Pashto; Marathi, Malayalam, and Burmese (Mranmabhasa) are next to each other instead of having say Pashto and Persian (Farsi) next to each other where they don't start with the same sound. That should make it easier to find a given language as the language box gets bigger. --Bgo eiu (talk) 18:03, 19 August 2022 (UTC)
Next time someone adds a language code to the template, if typing p.languageCodesSortedByName() in the debugging console as the documentation says, the languages will revert to the previous order. Andrew (talk) 18:20, 19 August 2022 (UTC)
@Bgo eiu: Your edits have merit, but as Wynndale points out, there should be a more durable way of implementing them. Could languageCodesSortedByName() be more nuanced than diacritic-folding the romanizations and sorting them alphabetically (the same approach that's built into MediaWiki)? Then again, maybe it won't matter for long, since the Translate extension would display these links automatically based on its own sort order. If these languages are currently hard to find in {{Languages}}, I suspect that creating stubs in them will do more for discoverability than polishing the sort order. After all, a language link is a lot easier to find among the list of existing translations than among the much longer list of redlinks that's hidden by default. – Minh Nguyễn 💬 05:46, 20 August 2022 (UTC)
Hmm, I assumed the order prior to my edit had been ad hoc because I was having trouble seeing what the order was based on (and therefore where to put the codes). In theory, if the function works by diacritic folding the Romanizations, that would look better than my edit or what it looked like before I edited --Bgo eiu (talk) 23:13, 20 August 2022 (UTC)
Alright, when I just tried p.languageCodeSortedByName() the output made more sense than what it looked like before my edit, but is not ordered by Romanization or language code or English label towards the tail (the Arabic scripts were in an order that makes sense, but why is Burmese after Thai? That it could put Pashto in the sort order even though it starts with a letter which doesn't exist in Arabic). In any case, it doesn't matter that much since p.languageCodeSortedByName() results in something not that different. It seems like it just doesn't Romanize Brahmic scripts.
I am not sure why Saraiki was removed either. Saraiki represents a dialect continuum between Punjabi and Sindhi, so if those languages have codes in the wiki it doesn't make any sense to omit it as you can derive translations more easily once a translation in one of these languages is available. Transcribing a Punjabi page to Saraiki is doable as it is a matter of replacing certain phonemes and word forms (there are even some words which are more commonly written in Gurmukhi and Saraiki Shahmukhi than in Punjabi Shahmukhi, so using that using it in conjunction might be helpful isn't out of the question). Further, Saraiki Wikipedia has articles that I might be more inclined to reference where they are of better quality than the Punjabi Wikipedia ones, and there is no line where Punjabi ends and Saraiki starts so it would seem more inclusive to let people pick between pa, pnb, or skr, rather than make it seem like certain dialects are preferred. So that's the logic there.
I did see the comment that said that a language has to have pages before adding it to the list, but the instructions also suggest that I would not be able to create a Saraiki page without an English page first and that to create a new page you should add it to the template, so I assumed the comment was just out of date/meant to be ignored. Whenever I get to a point where I feel comfortable writing Urdu that isn't Punjabi-pretending-to-be-Urdu, I would add Urdu and Hindi together for the same reason as adding Punjabi and Saraiki together; if the languages are similar to a degree of mutual intelligibility it's better they not stay separate. —Preceding unsigned comment added by Bgo eiu (talkcontribs) 23:42, 20 August 2022‎ (UTC)
@Bgo eiu: I may have oversold languageCodeSortedByName(): it doesn't have any way of getting romanizations, so all it does is get the native name of each language, normalize any Latin names among them (folding case and diacritics), and sort by Unicode codepoint. This has the effect of grouping most languages by writing system, which has been the template's behavior for a long time. I don't have anything against properly sorting by romanization, but we'd need to maintain a table of romanizations. – Minh Nguyễn 💬 07:09, 22 August 2022 (UTC)

(I wrote a little too much, but in short, if a Punjabi wiki page happens to be perfectly legible to a Saraiki reader, the question of "is this a Punjabi page or a Saraiki page?" is like asking "is tomato a fruit or a vegetable?" OSM Wiki doesn't need to be concerned with this question, and I am leaning towards wanting to avoid saying or implying "Punjabi is the same as Saraiki" where possible.) --Bgo eiu (talk) 23:59, 20 August 2022 (UTC)

Added Skr:Key:name:skr as a place holder from my phone if it would help; though it might be a bit before I flesh it out as I want to figure out how to render the wiki editor in a Punjabi/Saraiki friendly fixed width font first (this exists thankfully, and is necessary given I discovered editing Punjabi regexes on GitHub is complicated by some characters looking identical in some fonts). And how to get Latin script templates to be in the correct part of the sentence --Bgo eiu (talk) 00:18, 21 August 2022 (UTC)

Sorry to triple bump the thread, but in trying out using the Languages template, I've realized that clicking on Arabic script links doesn't even work without expanding the whole list anyway, so creating a stub doesn't really help to that end. I should look into how the Translation extension works. (And spend more time browsing Persian Wikipedia, as they've worked out how to deal with these kinds of quirks better than most.) --Bgo eiu (talk) 00:48, 21 August 2022 (UTC)

@Bgo eiu: The backstory is that the previous iteration of {{Languages}} listed many, many more languages indiscriminately, detracting from the template's primary purpose as a navigational aid among existing pages. A former contributor to this wiki insisted that {{Languages}} include any language with at least one page, and simultaneously added empty categories and subcategories in hundreds of languages, including many that had scant chance of ever having content on this wiki. Something about this template appearing on every page on the wiki must've given them some kind of rush, but paring back the list actually had a perceptible impact on page load names. I believe you're being more considerate, but the bar for adding a language remains more than reasonable: just one content page, however trivial. Notably, this standard has nothing to do with curating a coherent list of related languages.

At the time I redesigned {{Languages}}, I was unsure if the community here would even accept my shortcut of making the template's header and footer match the interface language instead of the page language. But since that seems to have stuck, I think we should consider dropping the list of redlinks altogether in favor of a single link for the interface language if the page isn't available in that language yet. If the user isn't using the wiki in their native language, they can use the Universal Language Selector (next to the user name at the top of the page) to search for their language within a much more comprehensive list. Getting rid of the list of redlinks would eliminate the annoying jank or jump that occurs on page load, especially on mobile devices.

 – Minh Nguyễn 💬 06:44, 22 August 2022 (UTC)

I relatively often use this template to create pages in Polish despite using English interface. Would be still possible to have listing of all not yet existing pages available somehow, even if hidden by default? Mateusz Konieczny (talk) 16:30, 23 August 2022 (UTC)
@Mateusz Konieczny: Yes, we could add something for that, but it could be generated dynamically instead of baked into every page's source code. – Minh Nguyễn 💬 00:35, 8 September 2022 (UTC)
Conclusion(?) or addendum - given that clicking on Punjabi and Saraiki doesn't work at all from the language table anyway, I've restored the config to be as it was before I edited, just with pnb and skr added to "minor languages." Setting it up like this: Skr:Key:name:skr the links actually work and I don't have to argue to add Hindi or Urdu to in it since it should be as easy as possible to add translations in these languages from Punjabi/Saraiki. Hopefully adding categories manually doesn't also break anything... --Bgo eiu (talk) 08:14, 21 August 2022 (UTC)

Wikibase file uses not shown on file pages (or in API)

Where a file is used by a Wikibase item, that use doesn't currently appear on the file's description page. For instance, File:Motorway-DE-A4-Aachen.JPG is used on highway=motorway (Q4980), but that item doesn't appear on the file description page under "File usage". This doesn't seem to be problem intrinsic to Wikibase, since it doesn't affect Wikidata. See, for instance d:File:30 Storeys Way, Cambridge (geograph 5521921).jpg, which correctly shows its use by d:Q26627430. Fixing this would help with my plan (above) to track this wiki's use of Commons files, because uses by Wikibase items also seem to be invisible to the MediaWiki API at the moment. --Ben Harris (talk) 10:24, 19 August 2022 (UTC)

Worked around by having a bot generating galleries Mateusz Konieczny (talk) 07:27, 29 October 2022 (UTC)
Mateusz meant Wiki:Files used by data items.
Is there anything we should do here? Is linking to data items on file pages technically possible? maro21 20:47, 19 April 2023 (UTC)

Deprecate status=draft?

If something is actually an incomplete draft or describes a failed idea - it should be moved to proposal space, without redirect.

If something describes actually use (in use), widely used (de facto) or unwanted (deprecated) tag then status of proposal does not matter at all.

In general, I propose to get rid of this status on tag pages and fix affected pages. Is there any valid use for that status? It seems to me that it just encourages putting drafts into main space instead of a proposal space.

See for list of pages with it (permalink). Is there any valid use there that would not benefit from changes mentioned above?

Pinging participants of previous similar discussion @AngocA: @Chris2map: is now listing pages which set status to draft Mateusz Konieczny (talk) 09:33, 8 September 2022 (UTC)
I just stumbled over this: Why is the "draft" status value still listed as an allowed possibility on pages like Tag_status#Status_values or on Template:Description?
PS: I also noticed that the markup of pages with the now apparently invalid status "draft" is broken: It shows the category wiki markup (e.g. [[Category:Tag descriptions with status "unsupported “draft” statusHelp translate this into English!"|aeroway holding_position_line]] ) instead of a link to the category, and the "status" field in the infobox suggests to icon for "Help translate this into English", even though the string is already in English.
-- Tyr (talk) 09:52, 13 September 2022 (UTC)
PSS: Wouldn't the status "draft" at least be desired for tagging proposals which are actually still in a draft state, like this example: ? --Tyr (talk) 10:04, 13 September 2022 (UTC)
"::I just stumbled over this: Why is the "draft" status value still listed as an allowed possibility on pages like Tag_status#Status_values or on Template:Description?" - mostly because that was recent change with minimal feedback, so in case of good counteraguments it is possible to roll it back. So I changed only what was necessary to start listing it in Category:Feature descriptions with incorrect status value so clearly invalid cases can be fixed. And maybe some valid uses can be found? Mateusz Konieczny (talk) 12:28, 13 September 2022 (UTC)
"Wouldn't the status "draft" at least be desired for tagging proposals which are actually still in a draft state, like this example" - I think that tag infobox templates should not be used on proposal pages. But editing templates to prevent category assignments in a proposal namespace is also possible Mateusz Konieczny (talk) 12:28, 13 September 2022 (UTC)
I thought that using the info box on proposals could be useful: it's nice to see the taginfo stats, to have the links to external tools and to see how the image and description of the proposed tag would look like. But ok, I guess we could live with using the "undefined" value instead for these cases.
More importantly, I think the way this "deprecation" is implemented is pretty confusing: as it doesn't reflect the documentation and produces broken wiki markup and wrong error messages. Is there no better way to sort wiki pages into categories based on their status value?
-- Tyr (talk) 11:48, 14 September 2022 (UTC)
If someone has a simpler way to do this, help is welcome! Especially handling of invalid statuses definitely can work better in general and broken wiki markup should be not produced, rather a clear warning Mateusz Konieczny (talk) 07:11, 27 September 2022 (UTC)
Note: in case of keeping this value after all, then changes in also need to be reversed. Mateusz Konieczny (talk) 07:11, 27 September 2022 (UTC) - has only few remaining uses Mateusz Konieczny (talk) 15:54, 18 October 2022 (UTC)
I strongly support Mateusz's arguments. It makes sense. It's good that we got rid of this status. I see that draft status is not supported right now and it has been corrected on tag and key pages. So I've corrected other occurrences of this status in places where it still remained, including data items ([14] 69 -> 3). Category:Tag descriptions with status "draft" and Category:Key descriptions with status "draft" are empty now and won't be populated anymore because the template was changed. However we still have Category:Proposals with "Draft" status. maro21 23:23, 19 April 2023 (UTC)
Resolved: all 'draft' status occurrences have been corrected

drop status=rejected

That is status of a proposal, not of a tag.

"in use" tag where related proposal was rejected is still "in use" and should not get "rejected" stamp.

Also, this discourages making proposals, as proposal may lead to rejection vote and ugly stamp on wiki documentation page.

Not sure whether we had deliberately bad proposal to sabotage tag and get it status=rejected, but lets not encourage this.

Is there any case where tag page (not proposal page!) benefits from status=rejected being available?

Mateusz Konieczny (talk) 06:33, 2 September 2022 (UTC)

@Mateusz Konieczny: I agree that the prospect of a "rejected" proposal might be a discouragement to bringing forward voting. Would a tag that was previously documented as status=rejected be tagged as status=proposed, or status=deprecated? Diacritic (talk) 02:22, 6 September 2022 (UTC)
@Diacritic: No automatic change, this depends on a tag. It can status=deprecated, status=in use, status=de facto, or trigger a discussion to confirm deprecation etc Mateusz Konieczny (talk) 04:30, 6 September 2022 (UTC)
Right now Key:landuse:secondary would be affected - not sure is it status=deprecated or status=in use or "ask wider community" Mateusz Konieczny (talk) 04:39, 6 September 2022 (UTC)
Also would be affected and would need an update Mateusz Konieczny (talk) 08:00, 7 September 2022 (UTC)
"Is there any case where tag page (not proposal page!) benefits from status=rejected being available?" I think yes: If the tag was invented in the proposal and wasn't in use before. In that case the wiki should be somewhat prescriptive and make clear that the tag was considered but found to be bad. But of course: A tag should not become rejected by a rejected proposal if it was in use before. For that a deprecation proposal should be necessary which has a high hurdle. --Lkw (talk) 10:25, 8 September 2022 (UTC)
In this case I would consider deprecated or obsolete as a fitting status Mateusz Konieczny (talk) 12:40, 13 September 2022 (UTC)

I've been thinking for a long time about replying in this thread. In the meantime dealing with other statuses. Yes, I agree with Mateusz that this is a PROPOSAL status, not a tag status, and tells the user nothing about whether or not to use the tag.

We have many "negative" statuses: deprecated, discardable, obsolete and... rejected. The difference between deprecated and rejected is that for deprecated tags we usually have an alternative tag to use, but we don't have it for rejected ones.

Status=rejected looks for a user like "the tag is rejected so it should not be used". Then the question arises "Then what to use instead?". Such a question is answered by status=deprecated, because then it says what is a replacement for that tag.

The same with abandoned status - a proposal can be abandoned, but not a tag.

Let's analyze as an example the vote on amenity=training. The tag had about 3,000 uses before the vote, then there was a vote that did not pass. But the status of the tag doesn't change because of it: [15] People in the vote didn't say that the amenity=training tag was bad, because the vote was also about other tags. Often it is the case that the proposal applies to many tags, not one.

If the status rejected were to remain then:

  • It should be called "rejected proposal" or "in use but proposal was rejected".
  • The tag should have exactly 0 uses (currently there is no such situation).

I retagged existing keys and tags with this status:

So Category:Key descriptions with status "rejected" is empty now.

So Category:Tag descriptions with status "rejected" is empty now.


  • Let's drop rejected status.
  • Let's keep status 'rejected' only for proposal. [23]
  • For tags with rejected proposal and minimal usage of the tag let's switch status to 'proposed'.
  • For tags with rejected proposal but when the tag is in use, let's switch to 'in use'.
  • If the tag was rejected in the voting, this is important information and should be mentioned in the beginning of the article but if it's in use, the status would be "in use". maro21 10:10, 3 May 2023 (UTC)
+1. I was actually going to propose something similar to your solution a while back but never had the time. Although with one difference being I was going to suggest introducing a "planned" status for proposals that are still in the planning stages. Since I feel like "proposed" insinuates the tag has been put forward for consideration or discussion by others when often times it hasn't been. Your suggestion is good though. --Adamant1 (talk) 10:30, 4 May 2023 (UTC)

How can I list tags with data items but have no OSM Wiki page?

Special:PrefixIndex/Item: is not helpful as it lists them as alphanumeric soup, not as tags.

Category:Redirects connected to a data item is not helpful as it lists only cases where redirect exists

I am also fine with API call (I guess that Special:PrefixIndex has matching one?), if there is nothing human readable

For bonus points, listing only data items with actual content (and skip blank entries like ) would be great

Mateusz Konieczny (talk) 11:34, 6 September 2022 (UTC)

Using Sophox or Talk:Wiki#Install_the_WikibaseCirrusSearch_extension. maro21 20:50, 19 April 2023 (UTC)
And Special:ItemsWithoutSitelinks ? --Chris2map (talk) 20:30, 4 May 2023 (UTC)
Almost no tags there. Mostly groups. maro21 20:48, 4 May 2023 (UTC)
Yes, I had already once maintained some. Well, we are missing a list of data items that have a sitelink but the page does not exist. --Chris2map (talk) 08:05, 5 May 2023 (UTC)
What is a sitelink? maro21 15:13, 5 May 2023 (UTC)
A sitelink is the connection between a data item and a wiki page. It must be set manually (Special:SetSiteLink) when creating a new data item to establish this connection (since Special:ItemByTitle doesn't work). E.g. Special:SetSiteLink/Q6787/wiki. See "Set item sitelink" at bottom of main menu to the left on item pages. --Chris2map (talk) 16:49, 5 May 2023 (UTC)
I see. So in cases like this one Item:Q997 the bot set sitelink to Key:REF when creating the data item, although the page Key:REF doesn't exist. So we won't find such items without a Wiki page because they aren't listed at Special:ItemsWithoutSitelinks. maro21 18:04, 5 May 2023 (UTC)
Exactly! I think a LUA app or module could do the job and a Sophox/SPARQL query might be possible, too. But I don't know how to code them. --Chris2map (talk) 08:27, 6 May 2023 (UTC)

Enhanced not-found messages for non-English users

Stuck: not enabled for all languages for now as it is a bit tedious. Will be enabled in future. Mateusz Konieczny (talk) 15:20, 22 July 2022 (UTC)

note: this was extracted from section of "Enhanced not-found messages" in "Redundant pages for "building block" tags"

@Minh Nguyen: Would it be possible to enable at least English summary? "It's pretty straightforward to add these customizations to every language, but first we need to refactor MediaWiki:Searchmenu-new to be more maintainable" was mentioned above but I want to extract it here as it is a major blocker (I tested browser set to requests Polish and no such info is shown in such case) Mateusz Konieczny (talk) 08:30, 21 July 2022 (UTC)

@Mateusz Konieczny: I've added MediaWiki:Noarticletext/pl, MediaWiki:Noarticletext-nopermission/pl, MediaWiki:Newarticletext/pl, and MediaWiki:Searchmenu-new/pl. It is straightforward but would be tedious to enable for every language; I haven't gotten around to it yet. (Enabling the Translate extension on these messages would make it super simple for language speakers to maintain these customized interface messages in their own languages.) – Minh Nguyễn 💬 07:13, 22 July 2022 (UTC)

Assigning additional new data administrator for data item tasks

Resolved: --Chris2map (talk) 20:20, 4 May 2023 (UTC)

Hi there! IMHO it would be good to have a second data-admin (user with administrator rights for data items) as mentioned here. For now only one user (Yurik) has to fulfill this role. Granting him a vice (runner-up) would be fair, wouldn't it? Is there an established process or example how to initiate this? Who can set admin rights? I assume the other wiki admins could. Maybe several of them could consult on this? --Chris2map (talk) 08:25, 10 September 2022 (UTC)

Wiki:Bureaucrats can set admin rights Mateusz Konieczny (talk) 08:27, 10 September 2022 (UTC)
It would be great to have more than one data item administrator around here. There are a lot of opportunities for new properties that would go beyond merely mirroring what's in infoboxes, and probably a lot of things that should be cleaned up in the meantime. – Minh Nguyễn 💬 06:21, 12 September 2022 (UTC)
+1, especially because Yurik seems to be inactive. --Push-f (talk) 13:19, 29 September 2022 (UTC)

Anyone has idea for which specific person should be selected? Maybe User:Minh Nguyen? Mateusz Konieczny (talk) 07:26, 29 October 2022 (UTC)

@Mateusz Konieczny: I'd be willing to serve as a data administrator in addition to my current responsibilities as an administrator. I guess there would need to be a straw poll somewhere, similar to the process for adding an administrator. As a first step, I created Wiki:Data administrators, since we should have a page about each of the roles on this wiki. Regardless of who you'd like to nominate for this role, we can hold the straw poll on the talk page there (so it doesn't get buried here) and post an announcement here and in Template:News. – Minh Nguyễn 💬 00:11, 2 November 2022 (UTC)
@Minh Nguyen: I'm already watching notifications for Wiki:Data_administrators. My account is too new to OpenStreetMap, and I am still learning the specifics of the OSM data model (so I will not even try to propose myself for something like this). However, what we could start doing for Data Items property is have discussions similar to Wikidata. 3 references of such discussions (which actually shows that admins mostly respond to consensus) there: , and so people like me and others could comment if need. But I do agree that is always good idea have at least one backup. --EmericusPetro (talk) 01:55, 2 November 2022 (UTC)
Wow the @Minh Nguyen: already have experience on this xD! Sorry, I just noticed moments ago. He proposed tabular case data (P8204), OpenStreetMap numeric user ID (P8754), OSM Name Suggestion Index identifier (P8253) and others on Wikidata. I'm very sure he know the drill EmericusPetro (talk) 03:32, 3 November 2022 (UTC)
Oh yeah, not to worry, I wouldn't act unilaterally without discussion when creating new properties. We already have enough avoidable deprecated properties like (DEPRECATED) excluding region qualifier (P27). – Minh Nguyễn 💬 08:02, 3 November 2022 (UTC)
I think that it would be fine if you would nominate yourself? Or are you waiting for someone else interested in data items to start the process? Mateusz Konieczny (talk) 04:23, 10 April 2023 (UTC)
I see it the same way and support the nomination and designation. @Minh Nguyen: Are you still willing and if so, are you going for the bureaucrats? Or should / may I contact them with a nomination request? (In case I would ask and ping the following bureaucrats here on Talk:Wiki and simultaneously write email messages: Harry Wood, Lyx, Pigsonthewing, Steve). --Chris2map (talk) 09:26, 16 April 2023 (UTC)
I support Minh Nguyễn. Let's do it. maro21 20:53, 19 April 2023 (UTC)
Yes, good idea. Andrew (talk) 21:03, 23 April 2023 (UTC)

@Chris2map, Maro21, and Mateusz Konieczny: Thanks for your support – yes, I would be willing to clear some of the backlog of data item administrator tasks. – Minh Nguyễn 💬 23:17, 22 April 2023 (UTC)

@Yurik: Before we go ahead asking for an additional data-admin, I want to ask you for your view on that. - My motive is to share all tasks, duties and burden. I would also like to take this opportunity to express my thanks and respect for your great work in providing the data items in OSM! Regards --Chris2map (talk) 20:36, 24 April 2023 (UTC)

@Chris2map: thanks for the ping, I'm all for increasing the numebr of data admins. Thx! --Yurik (talk) 20:51, 24 April 2023 (UTC)
@Yurik: Wow, that was quite instant! Thanks a lot for your quick and positive response! --Chris2map (talk) 20:58, 24 April 2023 (UTC)

Request @Harry Wood, Lyx, Pigsonthewing, and Steve: Dear Wiki Bureaucrats! As you can read in the comments above, we hope to add a second "data admin" to handle the data item tasks. We would also already have a candidate: At Mateusz Konieczny's suggestion, Minh Nguyễn has agreed to take on this task. – Therefore, on behalf of the users involved (Mateusz K., Minh N., Push-f, EmericusPetro, Andrew (Wynndale) and Chris2map (me)), I hereby request that the data-admin rights be assigned to Minh Nguyễn. – Kind regards --Chris2map (talk) 21:43, 24 April 2023 (UTC)

Done. --Lyx (talk) 09:12, 29 April 2023 (UTC)
@Lyx: Thank you for the straightforward handling! @Minh Nguyen: Congratulations! --Chris2map (talk) 10:30, 29 April 2023 (UTC)
@Lyx: Thank you, and thanks to everyone for your support. I'm working through some of the low-hanging fruit that has been requested lately. I'll be traveling the next couple weeks, but please ping me if you're blocked on anything and I'll do my best to respond. – Minh Nguyễn 💬 08:29, 30 April 2023 (UTC)

Wiki upload is sometimes not marking images as own work despite uploader selecting such option


Ideally someone(TM) would fix it Mateusz Konieczny (talk) 08:42, 23 September 2022 (UTC)

Template:GPL on images

I just noticed that Template:GPL is used 186 times on images in the File:* namespace.[24]


This work is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or any later version.
This work is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See version 2 and version 3 of the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

This template should only be used on file pages.

Note that the template says: "This work is free software" ... which obviously doesn't apply to images. I think the template should be reworded to clarify that this is a screenshot of free software. --Push-f (talk) 15:09, 1 October 2022 (UTC)

Both the template and the license were not invented to be used with images, to my knowledge. Therefore it cannot fit properly. I would leave the text as it is to match the license. Our templates are not all made exclusively for images. There are better licenses for images that should be used. In the existing cases where the source is GPL, it's just the way it is. --Chris2map (talk) 16:16, 3 December 2022 (UTC)
@Push-f: I took a second look and I didn't quite get your point at first. Now, I added "This is a screenshot" to the template when it is applied on filepages (in the File: namespace). I think this causes less confusion, too. What do you think? --Chris2map (talk) 16:34, 29 May 2023 (UTC)

How does one add a web font for use in-wiki?

In translating pages to Punjabi, such as Pnb:لُغت, I have been using Template:Nastaliq combined with some external font links in my custom Common.css file to get the script to render in the Nastaliq style. Essentially what this does is it uses different letter shaping and connecting patterns than would be seen otherwise. This has an impact on legibility, as languages such as Punjabi or Urdu are typically only written this way. Wikipedia includes Nastaliq web fonts for rendering these languages for reference, so this is something that users on that platform would be used to. Unfortunately, Android is a holdout in including a Nastaliq font by default, so hosting a web font is the best option at the moment.

The font I would like to include if possible is the Gulzar font, available at, which does a good job at rendering text in a "non-calligraphic" way while remaining true to the typical letter styles of Nastaliq typefaces. --Bgo eiu (talk) 22:49, 1 October 2022 (UTC)

@Bgo eiu: Ideally, MediaWiki would bundle a suitable Web font as part of the Universal Language Selector extension, which is installed here. That would allow users to click on " پنجابی" at the top of the page, then go to " ڈسپلے ترتیباں" and "لپیاں", then change "پنجابی لئی فونٹ چݨو" from "سسٹم فونٹ" to Gulzar. I see that you've already requested the addition of Gulzar to ULS. If a workaround is urgently needed, it might be possible for a user script or gadget to embed a Web font using a massive data: URI in an @font-face rule, but I don't think it would be a good idea to enable by default for performance reasons. An externally hosted font would get around some of that issue, but it would present both privacy and security risks. – Minh Nguyễn 💬 21:15, 11 October 2022 (UTC)
Ah, I assumed this would have to be implemented separately for different media interfaces, in that case, the Phabricator ticket should be fine. It's not urgently needed; I use an external URI with @font-face in my user settings but this is not really needed in the CSS once that goes through. --Bgo eiu (talk) 23:37, 11 October 2022 (UTC)
@Bgo eiu: I'm not entirely sure about the mobile view. There doesn't seem to be a way to access ULS from there, other than to switch to the desktop view. – Minh Nguyễn 💬 09:08, 12 October 2022 (UTC)
@Minh Nguyen: Are the ULS hosted fonts accessible from the CSS? I forget to check what things look like in the mobile view because I set everything to desktop mode to get the missing features anyway. That may be something that's hard too do much about short term, it shouldn't be anything that's too much effort on the wiki's part to implement. Google developed the Nastaliq font that iOS includes by default, it could be a matter of finding the right Android developer's e-mail address. --Bgo eiu (talk) 03:55, 14 October 2022 (UTC)
@Bgo eiu: Not sure, but you can use the mobile view from your browser and inspect the loaded fonts in your browser's Web inspector. It could be that the fonts do load despite a missing ULS UI. The mobile view does load gadgets and user scripts like normal. – Minh Nguyễn 💬 02:13, 2 November 2022 (UTC)

Missing language description at compound pages

any idea why some rare languages miss descriptions?

For example

See confirming code assignment (the same applies to other codes listed here)

Compare with compound pages generated

Making tag pages or data items are quite pointless here, so improving compound pages would be nicer (though making tag pages is also a workable solution)

@Minh Nguyen:

Mateusz Konieczny (talk) 18:17, 11 October 2022 (UTC)

@Mateusz Konieczny: There are multiple issues:

  • Module:Tag currently falls back to a language name lookup as a last resort, if there isn't a data item about the key by that name. name:sat=* comes back with a blank description from sat (Q14162), merely because sat=* has been tagged hundreds of times (maybe a typo of seats=*?). Otherwise it would come back with "Santali". This also affects name:mnc=* (mnc (Q11789)) and name:man=* (man (Q11555)). I guess it makes sense to invert the order of precedence, but we'd have to do it only for keys that can be language-qualified, such as name=* and destination=*. This could be tricky: payment:id=* isn't the key for saying whether you can pay in the Indonesian language, but description:payment:de=* is the key for describing the payment method in German. Do you know of any references for making this order of precedence more accurate? For now, I've taken a conservative approach of only introducing the language fallback when we're sure there isn't another reason for a two- or three-letter subkey.
  • kio, yuf, mhj, lud are a mystery to me. They are valid ISO 639-3 codes, and there aren't items for kio=* et al. Scribunto gets the language list from the CLDR extension. Special:Version says we're using this commit of the extension, which last updated language names to CLDR 37. CLDR has always had entries for these codes, but the CLDR extension seems to lack anything about them. I think the next step would be to file a bug report against the MediaWiki-extensions-CLDR component.
  • The CLDR project itself doesn't intend to maintain translations of language names of all the valid ISO 639 codes. Instead, they expect clients to fall back to the IANA registry, which is authoritative. T168799 tracks getting this fallback into MediaWiki. As a workaround, the English Wiktionary has compiled its own data modules incorporating the entire registry (along with lots of other lexicographical data about each language) in Lua format. Feel free to copy these modules if you think the maintenance overhead would be manageable.

 – Minh Nguyễn 💬 19:35, 11 October 2022 (UTC)

I guess we should delete as pointless AND causing problems. Any idea how we can get data item deleted? Mateusz Konieczny (talk) 20:00, 11 October 2022 (UTC)
You can tag the talk page with {{Delete}}. Make sure to note that you'd like the item deleted, not just your request for deletion. ;-) Before outright deletion, we should ideally attempt to figure out the intention behind the key's usage. If it does turn out to be a typo for seats=*, then we should change the status (P6) to deprecated (Q5061) and add a replaced by (P17) to the correct key. I've modified Module:Tag to avoid using items that redirect, because we normally don't deprecate just one component of a key. – Minh Nguyễn 💬 20:36, 11 October 2022 (UTC)
"Do you know of any references for making this order of precedence more accurate?" - no, and I am tempted to just create wiki pages for such name:lang cases. At most I can imagine maintaining list of tag parts which presence makes language context more likely (name, note, description...) Mateusz Konieczny (talk) 20:02, 11 October 2022 (UTC)
I think that would be a useful wiki page to put together, not only for this 404 page but for a lot of other things too. Eventually I want Module:Tag to take over {{Tag}}; it could come with smarts to decide whether to link a key part or not, so people don't have to choose between |: = and |subkey =. Editors could also adapt this list to internationalize more fields besides name=*. It would be a logical extension to Order of key parts. – Minh Nguyễn 💬 20:36, 11 October 2022 (UTC)
Order of key parts may be related Mateusz Konieczny (talk) 21:01, 11 October 2022 (UTC)
"I think the next step would be to file a bug report against the MediaWiki-extensions-CLDR component." - not sure is it worth doing, in my experience MediaWiki phabricator is a black hole where you at most get WONTFIX. Mateusz Konieczny (talk) 20:05, 11 October 2022 (UTC)
It's a big project. Language-related issues have a better shot at getting looked at, because internationalization matters so much to the Wikimedia community. At least someone more familiar with the extension could point out if the issue has been reported before. – Minh Nguyễn 💬 20:36, 11 October 2022 (UTC)
The extension documentation says you can download the latest CLDR data and it'll use it. Maybe we should ask the operations team to give it a try. – Minh Nguyễn 💬 20:42, 11 October 2022 (UTC)
Would an updated CLDR address documentation in currently missing languages? Andrew (talk) 21:19, 11 October 2022 (UTC)
@Wynndale: I think that's a different language list, or at least it seems like it based on the different instructions at d:Help:Monolingual text languages and [25] for requesting a monolingual text language. – Minh Nguyễn 💬 09:03, 12 October 2022 (UTC)
"Feel free to copy these modules if you think the maintenance overhead would be manageable" I will try looking into this. Mateusz Konieczny (talk) 20:11, 11 October 2022 (UTC)
By the way, Module:Languages/config already overrides the language table with a few things we need for this wiki. We could add more to that module, but it's used in {{Languages}}. We had problems in the past when a former contributor attempted to turn this wiki into the go-to source for CLDR corrigenda, so I've hesitated to start down that road again. If we're able to copy Wiktionary's modules verbatim, then we could tell people to hash out their disagreements with CLDR or ISO upstream at Wiktionary. – Minh Nguyễn 💬 20:36, 11 October 2022 (UTC)
@Minh Nguyen: thanks for investigation! Mateusz Konieczny (talk) 20:11, 11 October 2022 (UTC)

Use Wikibase to document OSM software

Recently I had updated the 3D development page extensively. Through doing this, I realized that many of the software frameworks, map viewing software, and other developer tools that support 3D data are also present on the Software libraries page.
I was thinking, so that we don't have to maintain the same data in 2 different locations, it would be nice if we created data items for each of the software frameworks that described their capable features, language, platform, license, release date, and integration with other software. Then we could show tables using that would derive the data from Wikibase by querying Sophox. Of course, this would require that we fix .

Thoughts? Lectrician1 (talk) 18:49, 1 November 2022 (UTC)

@Lectrician1: I think your proposal is actually a use case for a more generic use of Wikidata:Listeria! On my sandbox page I'm already drafting some SPARQL queries (for now mostly to Wikidata, not yet to Sophox) but I really like the idea of make your proposal more generic! Maybe sort of allowing changing the endpoint, like what happened with when I was proposing have a Template:WikidataSPARQL which is not necessary anymore. Also, the alternative of a more generic, means tests could start with or without Sophox/sophox/issues/27. The property proposal by @Wynndale: could occur parallel to the preparation of equivalent to Wikidata:Listeria, however sometimes the queries would be federated or we might need to discuss where to use as reference store. For example, Wikidata already have some OpenStreetMap local chapters (see User:EmericusPetro/sandbox/List_of_OpenStreetMap_local_chapters) updated by others so by create them there, we make available for a broader audience. EmericusPetro (talk) 22:48, 1 November 2022 (UTC)
That would make some sense. As a first step you could draw up a list of properties for the new data administrator to set up. --Andrew (talk) 20:22, 1 November 2022 (UTC)

I agree that there should be a more structured way of maintaining information about OSM-related software libraries. Years ago, there was an attempt to harmonize this wiki's software pages and keep them in sync with master tables such as Comparison of iOS applications. This effort relied on Tordanik's TTTBot to scrape individual articles' infoboxes, but once that bot stopped running, these tables fell into disrepair and eventually people also lost the motivation to maintain the infoboxes. Outdated values are especially noticeable with mobile applications that publish releases or change prices frequently. There's also a lot of discontinued software that doesn't age well, making any table seem less relevant. (In 2016, I split out these master tables from articles such as iOS and Android in order to present a less maintenance-intensive gallery that intentionally doesn't go into as much detail.)

Ideally, we would aim a little higher and contribute this data about software packages to Wikidata, to the extent that Wikidata would accept it. For one thing, this would result in less duplication of work, since the most well-known OSM software is already on Wikidata, such as Overpass Turbo (Q62057787) and Open Source Routing Machine (Q7096221). Moreover, Wikidata items can take advantage of much better integration with the Wikimedia ecosystem: Vespucci (Q60050619) can state that it's named after Amerigo, and if not for a spam filter bug, Github-wiki-bot would be able to automatically update Organic Maps (Q107078602) with the latest version number as soon as it's released.

I'm reminded of how this wiki can accept image uploads, but we direct users to upload all but the most ephemeral images to Wikimedia Commons instead, so everyone can use them. The difference is that this wiki isn't a client of Wikidata and doesn't have federated properties enabled, so wiki pages here can't automatically pull values from Wikidata. To me, this would be a decent reason to maintain software items in our Wikibase instance, but we should keep the properties to the minimum necessary to serve this wiki's infobox and navigational needs. If we really need up-to-date version numbers and consider a basic Wikidata link insufficient, then we could rely on a bot to keep the infoboxes up-to-date, reminiscent of TTTBot but based on Listeria. However, I don't consider the version numbers to be a pressing matter, since Wambacher's SoftwareWatchlist already has that covered and even posts updates to the new Discourse site. [26]

 – Minh Nguyễn 💬 01:43, 2 November 2022 (UTC)

The UnlinkedWikibase extension came to my attention today via the Wikibase Telegram chat. [27] It claims to give arbitrary pages here read-only access to arbitrary Wikibase items on remote Wikibase instances. I have no idea how that works, but it sounds magical. Unfortunately, it's still a beta extension that the sysadmins would need to countenance installing despite their qualms about Wikibase or Wikibase Client. – Minh Nguyễn 💬 23:28, 2 November 2022 (UTC)
(Rocha here) My comments
+1 to as far as possible/reusable, we use Wikidata, so this benefits a broader ecosystem
+1 to set up automations. I'm comfortable with a bunch of programming languages and even do code on the public domain. Could help with this.
+1 to we have a plan to "keep things updated" (maybe automatically synchronize things from different sources etc). I think that even if someone like me created the automations, we should have a backup plan assuming I could not provide a response in time. Actually document the whole thing preparing for it.
+1 I do not have this ready now, but in theory it would be viable to let something mirroring some data from Wikidata to the OSM data store.
Said all this, extra comments:
A: I believe that even if items are on Wikidata, for things that are sort of very relevant to OSM (but not about the OSM data itself), for example, we could have sort of "WikiProjects" like the, but for for itens like User:EmericusPetro/sandbox/List_of_OpenStreetMap_local_chapters, which both explain how to query the data, how to "update it" etc. Also, such sort of WikiProjects could allow feedback if someone needs more complex use, so we have examples and shape the data for all them.
B: Since SPARQL is very powerful, if we start to have very important things on Wikidata, I could create generic configurable scripts that monitor potential vandalism/drastic human error. However, minor errors (like labels) might generate too much false positives, so would only worth under small periods (also, Wikidata allow protect items for new accounts, but this rarely is necessary; but yes, we can request permanently lock some items, even if are on Wikidata and not here)
C: Since I'm new here (and not sure the whole Data items history) if setup some WikiProjects, it will tend to be for things not already done by something else, and then do a good documentation on how people can keep updated it. The heavy work already tend to be done at start
EmericusPetro (talk) 03:32, 2 November 2022 (UTC)
Is there some reason to not do it in Wikidata? Would they delete items about minor software? Mateusz Konieczny (talk) 18:23, 8 November 2022 (UTC)
@Mateusz Konieczny: They wouldn't as a general rule, but based on the notability guidelines (which are much laxer than Wikipedia's), administrators would delete items that don't say much of anything and aren't used by other items. For some of the tools we document on this wiki, it would probably be difficult to come up with anything to say on Wikidata. But many of the tools would be plenty notable enough for Wikidata. – Minh Nguyễn 💬 11:22, 9 November 2022 (UTC)
"The entity must be notable, in the sense that it can be described using serious and publicly available references." - I wonder is public github/gitlab/codeberg repository good enough Mateusz Konieczny (talk) 13:12, 9 November 2022 (UTC) @Minh Nguyen:

@Mateusz Konieczny: To satisfy this notability criteria, you'd provide at least one reference or external identifier, as we do for many items that NSI needs. However, the source code repository (P1324) property isn't considered a property for an identifier that suggests notability (Q62589316); after all, one can create a GitHub repository just by clicking a button. Fortunately, there are many other sources to draw from. For mobile applications, App Store app ID (P3861), Google Play Store app ID (P3418), or F-Droid package (P3597) would suffice. I think a property proposal for a Transifex project ID or similar would probably get approved easily. An OSM mailing post by the author announcing the software would probably work as a reference, considering that Wikipedia has a {{Cite mailing list}} template for just this purpose.

Note that there's an alternative notability criterion, structural need, which is sometimes easier to justify. For example, if another notable item links to it with depends on software (P1547), then it's notable too.

 – Minh Nguyễn 💬 23:15, 9 November 2022 (UTC)

@Minh Nguyen: So you cannot create wikidata items for say individual waste baskets, even if they have some individual ids? From reading that rule it seemed that proving existence is enough and there is no need to demonstrate importance Mateusz Konieczny (talk) 06:18, 10 November 2022 (UTC)

@Mateusz Konieczny: Your interpretation was correct, but you do need to prove its existence somehow. If it has an ID that's assigned as part of some scheme you can identify, then create an item about that scheme (providing a reference about it) and add a catalog code (P528) statement to the wastebasket's item. As a protection against misinformation, Wikidata doesn't let you just handwave about "local knowledge", and it generally doesn't accept user-generated content as authoritative references. There's an ongoing discussion about NSI, which is borderline, being curated based on user-generated content in OSM. However, I've never had a problem with using Mapillary or KartaView images as references. (I try my best to add flag:wikidata=* to every flagpole I map. Sometimes a Mapillary or KartaView image is the only reference I can find for an obscure flag design.) Alternatively, you can take a photo of the wastebasket and upload it to Wikimedia Commons, then satisfy the structural need criterion either by adding an image (P18) statement to the item or by adding the item to the image's "Structured data" tab.

The difference between the wastebasket and the GitHub repository someone created by accident is that proving the repository's existence by linking to the repository is sort of a circular argument. By that logic, Wikidata could double in size tomorrow by creating an item about every existing item, but that would obviously be impractical. This guideline exists to ensure that people focus on creating non-empty items that can stand up to scrutiny.

 – Minh Nguyễn 💬 05:55, 11 November 2022 (UTC)

My opinion on this: the Wikidata tends to get more upset with things that could resemble self-promotion, in special as brands, see . For software, even a sort of "minor" software, as long as it is somewhat used, this might not be as problematic. The likely more danger here would be sort of intentional obvious spam (think for example if editing Wikidata makes even frontpages of other sites or apps shows that link) --EmericusPetro (talk) 23:09, 9 November 2022 (UTC)
@Mateusz Konieczny: I think that the major issue here is having something like Listeria, even if at first just using Wikidata. This use case in special (software) might already be allowed there. But the Listeria equivalent is a strong block for this feature, so we should already do some planning here. For example, I noticed that some people that already work with OpenStreetMap data items also edit things related to OSM on Wikidata, but by having Listeria here this would incentive everyone! --EmericusPetro (talk) 23:00, 9 November 2022 (UTC)
@EmericusPetro: should be resolved first, base Wikibase is causing technical problems big enough that sysadmins want to get rid of it. Convincing them to enable more Wikidata extensions is extremely unlikely before that problem will be fully solved Mateusz Konieczny (talk) 06:18, 10 November 2022 (UTC)
@Mateusz Konieczny: Listeria is a bot, not an extension. It would be up to someone to run the bot on their own machine, Toolforge (which is open to OSM projects), or perhaps the OSM dev server. – Minh Nguyễn 💬 05:55, 11 November 2022 (UTC)
@Mateusz Konieczny: So I took some time to write some points (even small parts of it would be too much on Talk:Wiki) on --EmericusPetro (talk) 12:35, 12 November 2022 (UTC)

@EmericusPetro: Is there anything to do it here as far as OSM Wiki is concerned? Mateusz Konieczny (talk) 17:44, 30 March 2023 (UTC)

@Mateusz Konieczny: Humm... I don't know if others have a different opinion, but I don't think so. I have no idea if there is any actionable answer to what was commented here. At least not soon. It may end up being left open indefinitely in the current situation. EmericusPetro (talk) 18:16, 30 March 2023 (UTC)


I propose to remove "Duplicate content in a file format which is better suited for the content (e.g. SVG instead of JPG for drawings or charts)" section. There is no need to handle or mention it specially and I see no reason suggesting that it should not be uploaded to Wikimedia Commons Mateusz Konieczny (talk) 21:31, 22 November 2022 (UTC)

+1 I support the proposed removal. Besides, there is a typo at the end of the first section "which are using Wikimedia Commmons." --Chris2map (talk) 17:59, 19 April 2023 (UTC)

Global policy with Commons, should we move files from OSM wiki to Commons

I recently saw the use of the {{Move to Commons}} template, and added it to a File:Street Side Parking.png file, @Dcapillae: had a good thought on the talk page (File talk:Street Side Parking.png) and that's why I'm starting the think here:
Should we move files to Commons? If not, why ? If yes, which files should we keep and which files should we move?

For my part, I have personally tried to put as little as possible on OSM Wiki (especially things that are impossible to put on Commons like Maxar satellite imagery). But I didn't think further. Can we trust Commons ? Should we trust Commons ? What could we gain by moving some of our files there ? Is it really useful? etc.

Besides, I want to thank @Mateusz Konieczny: for the work of cleaning and tidying up because it is not easy to do and it requires courage! By the way, this work of cleaning at OSM Wiki will have to be done anyway, no matter what our position is towards Commons, to make sure that copyright is respected in our free project on the Wiki. — Koreller (talk) 20:36, 25 November 2022 (UTC)

"Can we trust Commons ? Should we trust Commons ?" - I think so, they are relatively stable and well managed. Though maybe making backup of files we are using is a good idea - good project for anyone suspecting trouble. this may be a good first step Mateusz Konieczny (talk) 21:44, 25 November 2022 (UTC)
"What could we gain by moving some of our files there ? "
Free photos are more reusable and easier to find by others (better categorization, more normal location, more trustworthy in general)
Photos uploaded to Commons are immediately usable on Wikipedias and other Wikimedia projects making easier to illustrate OpenStreetMap articles across Wikipedias (or other related articles with OSM-related content)
Better review of licensing situation (for example, photos depicting modern statues in France are problematic due to FOP situation - there are some people on Commons aware of such traps and acting on it, while here for multiple years we had massive amount of clear copyright violations and noone noticed. Some were clearly labelled.). Though that is a bit of tough sell, as in other words it is "maybe your photo will be deleted due to obscure stupid laws"
Forces us to review licensing situation (again a bit tough sell, but it is worth doing)
Encourages people to upload to Commons in the first place. They have much better upload interface, ours is basically broken - see [28] [29] that results in well intentioned people uploading own photos and ending in limbo legal status anyway which is tremendous waste
Commons has some special tools like license verification bots allowing to confirm Flickr license claimed during upload
During transferring files often one finds clearly superior versions. For example this soon to be deleted local version is of much smaller resolution than full photo that I found during transferring it
Mateusz Konieczny (talk) 21:44, 25 November 2022 (UTC)
"I have personally tried to put as little as possible on OSM Wiki (especially things that are impossible to put on Commons like Maxar satellite imagery)" - and thanks for that, in case of uploading them locally it is likely that you would miss license or even worse "that is my own work" claim that would make things complicated. Also, such uploads are far more likely to be used by others (I benefited from that during StreetComplete development that people uploaded stuff to Commons rather some local wiki) Mateusz Konieczny (talk) 21:48, 25 November 2022 (UTC)
Wikimedia Commons is a separate project, and I don't see any reason to force someone or suggest moving. If a person who adds the template wants to use a file on Wikipedia or a similar project, they can always make a copy on Commons - it is not forbidden as long as the license is compatible. I think OSM-related files should be here, because in case someone wants to upload a new version, they will do it here. The {Move to commons} is a copy of a template from Wikipedia, which was created not to keep images on just one Wikipedia, but to make them available on Commons, so that other Wikipedias can use the image too. In our case, it is unnecessary. Besides, I think most of the files we upload here don't fit on Commons. maro21 20:59, 19 April 2023 (UTC)

Per language feeds of wiki edits?

Hi, I am very new to OSM community and looked for RSS feeds of the activities written in my language on this wiki. It seems some languages have their namespace (ex ES) but my language(KO) is treated as a plain suffix of the title of the page. So technically it is possible to subscribe to the Spanish feed from, but not for Korean. I see adding a new namespace is not the good solution based on some articles. But because the API supports tag filtering, I would subscribe a tag if there is a certain tag. It will be good if someone creates new AbuseFilters and manage them to automatically add the tags to edits when the articles start with '<LANGUAGE_CODE>:'. --Megumi2103 (talk) 10:08, 27 November 2022 (UTC)

@Megumi2103: A few languages have their own namespaces for historical reasons, but language namespaces aren't being created anymore; instead, pages are being created in the main namespace with prefixes that look like namespaces. It is possible to create tags and assign them using abuse filters, similar to the one we created one to track edits to data item descriptions, but it gets throttled too easily to be useful. We'd also have to create one per language, which could be a performance issue. For now, one alternative is to search for pages containing the language code and sort by freshness, like this search for Korean. However, I don't think MediaWiki offers an RSS feed of Special:Search. uses the CleanChanges extension to provide an option to filter Special:RecentChanges by language code; the operations team is responsible for deciding which extensions to install. [30] – Minh Nguyễn 💬 00:57, 28 November 2022 (UTC)
Follow up Github issue:

sport descriptions

Which version is better

I think that OSM tag description should describe OSM tag - not word used as value in tag. But probably Warin61 also has some good arguments for that version? (maybe they will convince me! Or I am the odd one in such case I can also live with this style) Mateusz Konieczny (talk) 06:44, 6 December 2022 (UTC)

The value of the tag sport=* should identify the sport, not how the entire tag is used. The key sport=* has a description that says For categorising any specific sport it does not say it must be used with some physical tag such as leisure=pitch. Look at other descriptions have have had a much longer history such as highway=primary? It is not described as 'Added to roads.' but rather details what kind of roads. Similarly the tag for sports should describe the sport? Think of someone who has no knowledge of, in this case, toboggans - a description should help them decide it this is the thing they are seeing? Warin61 (talk) 07:30, 6 December 2022 (UTC)
There's some odd exceptions to that. For instance sport=free_flying. So it's clearly not a hard and fast rule. Not that I'm saying Mateusz Konieczny's sentence is better either though. Really I haven't put that much thought into it. Except to play devils advocate. Also, I've always thought it was weird that sport=* could be used without leisure=pitch since you can't really "play within or on some physical feature" without it implying there's some kind of pitch that your playing on. Toboggan runs and similar things like race tracks might be the exception, but it's really mostly semantics. Except in horse racing, where a pitch is apparently the location of a bookmaker. Who would have thought? --Adamant1 (talk) 10:35, 6 December 2022 (UTC)
All for devils advocacy! On the 'exceptions' to requiring some physical feature, there are those on the tagging list who disagree with this view. For 'tracks' there is leisure=track and/or highway=track. And yes, horse racing is on a track .. not a pitch, that is an error should be shop=bookmaker? Warin61 (talk) 06:48, 7 December 2022 (UTC)
"horse racing is on a track." Sure, technically it's a track. But then the term "pitch" is only really used in soccer, and that's because it's origins come from cricket where that's what the field is called. In baseball the are pitchers, but the field isn't called a pitch. It's called a field. Basketball courts aren't pitches either. Nor are tennis courts. Yet they all those are still tagged as leisure=pitch despite it. I assume because they all share the common definition of "an area designed for practicing a particular sport, normally designated with appropriate markings", which could just as easily apply to a race track. The fact that race tracks aren't "technically" pitches doesn't (or shouldn't matter) anymore then the fact that basketball courts, baseball fields, Etc. Etc. aren't pitches either. That's the point I was making. --Adamant1 (talk) 22:39, 7 December 2022 (UTC)
Another 'definition' that could be better, leisure=pitch "an area designed for practicing a particular sport, normally designated with appropriate markings" .. possibly "an area arranged for a particular sport, normally with appropriate markings"??? Anyway back to sport value definitions, "sport=toboggan description: Added on toboggan runs, toboggan sport shops etc" .. the word 'toboggan' may not be understood by the mapper .. so repeating it in the 'description' does not help... what is 'toboggan'??? Responding with 'toboggan is toboggan'... err no. Warin61 (talk) 09:24, 29 December 2022 (UTC)

Category:User images

I propose to migrate Category:User images to Category:Images depicting OSM Wiki editors as current name is not really clear (can also mean "images by users") Mateusz Konieczny (talk) 06:03, 7 December 2022 (UTC)

I'm actually in favor of moving the images to Category:Images depicting OSM Wiki editors but this category should be categorized in Category:User images. — Koreller (talk) 07:03, 7 December 2022 (UTC)
+1 — Chris2map (talk) 08:36, 7 December 2022 (UTC)
@Koreller: what kind of content will qualify for Category:User images but not for Category:Images depicting OSM Wiki editors? Mateusz Konieczny (talk) 09:08, 7 December 2022 (UTC)
@Mateusz Konieczny I'm talking about category. My idea is to have Category:User images as a super category which would contain Category:User trombinoscope and Category:User categories
(NB: Finally, I prefer the name of "Category:User trombinoscope" than "Category:Images depicting OSM Wiki editors") — Koreller (talk) 18:13, 7 December 2022 (UTC)
So "Category:User trombinoscope" would be for user account trombinoscope? And create separate category for each user account with images? Mateusz Konieczny (talk) 09:29, 8 December 2022 (UTC)
Yes I think it's a good organization
  • "Category:User trombinoscope" : for image depicting a user, and
  • "Category:User images" : to allow the user to have a category for all the files they have uploaded
(and categorize its two categories in "Category:User categories") — Koreller (talk) 09:33, 10 December 2022 (UTC)
The term "trombinoscope" is confusing to me. I do not know this term. I would like to have the term "images" in the new name of the category for user images showing user portraits, like suggested by Mateusz or something similar. - With the second part, a seperate category for each user containing images the user uploaded, there is Special:ListFiles. --Chris2map (talk) 10:27, 10 December 2022 (UTC)
Ah Twemoji 1f615.svg @Chris2map: why "trombinoscope" will be confusing for you ? And do you have a suggestion for naming two categories, one with images uploaded by users and the other for their portraits ?
In fact, the problem may be more to know what we would put behind the "User images" category, images depicting OSM Wiki editors or images per user.
I also find Special:ListFiles to be very inadequate, and very inconvenient for navigating through my own contributions, and it is for this reason that many users on Commons use a category like "Files by User:...", like me, and it's really valuable for files who can be upload on Commons. — Koreller (talk) 10:20, 11 December 2022 (UTC)
@Koreller: That was meant literally - I've never heard the word "trombinoscope" before. BTW, Special:ListFiles is not to bad. You can sort by date [31]. But feel free to use Category:Files by User:Koreller. I have absolutely no objections to that. - I can imagine that we use Category:User images as superordinated and put those images showing wiki editors in Category:Images depicting OSM Wiki editors. Everything else could be divided up into categories per user as wish. --Chris2map (talk) 11:59, 11 December 2022 (UTC)
Is "trombinoscope" even word in English? It seems to be in French Mateusz Konieczny (talk) 00:51, 12 December 2022 (UTC)
I think the English concept of a trombinoscope would be a directory of people with photos. There isn't really a specific, single English word for that though. Trombinoscope or otherwise. At least not that I'm aware of. --Adamant1 (talk) 02:00, 12 December 2022 (UTC)
I think that "face book" used to be used, but that meaning got eaten by FB (that based its name on this). And note that this photos can be not necessarily face - it may be full person, shadow of person etc Mateusz Konieczny (talk) 13:10, 12 December 2022 (UTC)
Hmmm, I've never heard the term before. But you might be right. In that case it just sounds like a photo album. The impression I get from the small amount of research I've done on it is that a trombinoscope is different somehow from just a regular photo album. Although I can't really say how, but that's at least the impression I get. -Adamant1 (talk) 02:06, 13 December 2022 (UTC)
I support migrating Category:User images to Category:Images depicting OSM Wiki editors. maro21 21:00, 19 April 2023 (UTC)

What is your opinion about possible paid editing? I am asking as I am planning new possible grant that may involve things specifically related to OSM Wiki.

While it would be beneficial and enable doing more improvements it also has some problems.

  • For start, I am already quite effective on OSM Wiki and maybe being more active and crowding out others is a potential problem.
  • It may discourage others from editing - after all if someone is doing the same/similar things and gets paid, why I would do it for free?
  • Anything else?

And please let me know if you think that this reasons or other are serious anything to make this a bad idea.

Benefits would be that I would be able to do some things that would be otherwise unfeasible to me (after all, how much time can be justified as hobby? likely less than I spend on OSM Wiki).

  1. Improving Mediawiki black magic
  2. finding images that have problematic copyright status, and replacing them with ones that are not worse (or far better) and have a clean legal status, then requesting deletion of old ones (for potential targets see ones listed on User:Mateusz Konieczny/cleanup as used on OSM Wiki - scroll down till you see yellow ones)
  3. Asking people to clarify licensing status of already uploaded files
  4. legal research (what kind of things we can even keep as "fair use"? What are limitation of "fair use"? Is English-Wikipedia style fair use even option for OSM Wiki goven its juridistriction? Which juridistriction is even applicable in case of OSM Wiki?)
  5. Write tool that make easier to find case where existing low quality tiny image used on OSM Wiki can be replaced by superior one ( maybe using and at Wikidata to identify possible depictions? )
  6. Write easy to use tool to make (2) or (3) easier to do by others?

My previous grants for OSM work was GSoC for OSM Carto development, for StreetComplete work.

If you are in any way disliking this idea, thinking that paid editing in any form is bad - or that any of proposed activities is not obviously good idea - please let me know (if you are for some reason unwilling to post here feel free to PM me via OSM private message).

Right now I am in extremely early stage, basically I am looking at list of my ideas for projects and thinking how can I spend more time on things that I wanted to do anyway.

Mateusz Konieczny (talk) 20:04, 9 December 2022 (UTC)

I think that the paid edition is not a problem as long as it respects the rules of the project.
I also think you do a good job, so having someone like you more often would only be good for the project.
Also, the fact that people are paid to improve the Wiki should be mentioned, (in my opinion this should be an obligation, like English of French Wikipedia for paid contributions)
I don't think you'll "crowd out" other people, there are just too few people (in my opinion) who improve Wiki and that we can't do anything about. The trick is to be open enough to accept constructive criticism (but this is not specific to paid contributions)
I wouldn't find my guide (NKMG) less accomplished or valuable because someone paid updates it, on the contrary, it improves the quality of the wiki and the resources available to contributors and that's the main thing. — Koreller (talk) 09:50, 10 December 2022 (UTC)
My 2 cents:
  • If you list previous grants, you should mention the OSMF microgrant you've received as well.
  • I don't have any objections to paid editing on the wiki, and I trust you to be transparent about it and handle any conflicts of interest responsibly.
  • I'm personally not convinced that the image cleanup work has a net positive effect for OSM, and I'm even more doubtful if it's the best possible use of your time. But that's for you and the people with the money to decide.
--Tordanik 15:00, 22 December 2022 (UTC)

Proposed automated edit

I would like to propose an automated edit in the wiki. It will move all proposals into the proposal namespace. A detailed description is available from User:TigerfellBot: Section 'Task Proposal namespace'. Are there any questions, comments, objections ... ? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:12, 21 December 2022 (UTC)

Can you publish source code running this edits? Will you also update links in data items/infoboxes? (or maybe leaving redirects is good enough? We need to keep them anyway as proposals are linked from outside wiki) Mateusz Konieczny (talk) 13:55, 21 December 2022 (UTC)
In general I agree, it makes sense. (this move itself was discussed already on this page). I guess that proposal instructions should be also updated. Mateusz Konieczny (talk) 13:57, 21 December 2022 (UTC)
I have not programmed anything yet but I plan to use Pywikibot's Movepages script. I actually forgot the Data Items. I hope that redirects are sufficient. I will update Proposal, Proposal process, and Wiki organisation manually. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:01, 22 December 2022 (UTC)
So do I. There are some redirecting pages in Proposed features/. What about those? A few simple ones with mistakes in writing in their names, I marked for deletion. --Chris2map (talk) 20:25, 21 December 2022 (UTC)
I plan to leave all redirects as they are. When you move pages, new redirects will be created and User:Redirect fixer will handle the existing ones if users do not intervene. I dislike deleting redirects because it might break externally used links and I do not see a benefit in deletion. If I break a redirect I will probably fix it manually i. e. not in an automated fashion. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:01, 22 December 2022 (UTC)
I think that's good. I would also not move the redirects to the new namespace. Just leave it as it is. Except for the ones with very simple typos, which the creators themselves would have deleted immediately if they could. --Chris2map (talk) 16:53, 22 December 2022 (UTC)

@Tigerfell: What is the status of this? Do you have source code now? Mateusz Konieczny (talk) 17:44, 30 March 2023 (UTC)

No progress yet. I hope I will find some time (+ new computer) in mid/end April. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 12:18, 31 March 2023 (UTC)
There is a suggestion to move French pages, too. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 11:38, 27 May 2023 (UTC)


I'm thinking about creating an SHACL (the W3C Shapes Constraint Language) page at SHACL here on the Wiki. But I would like to know opinions upfront, since the page is a bit more generic. The idea would be both a very short introduction of what SHACL is and how it could be used with OpenStreetMap with examples, to work as a gentle introduction for people interested in the topic. But anything more specific (e.g. more detailed uses) might need more specific page. So if it gets used let's say for how to convert Infoboxes and textual rules (too complex for allowing convert Tag/Keys automatically into SHACL by script) into stricter validation checks, dedicated page for that could exist. Would take some time, but how to group the related pages would become relevant. --EmericusPetro (talk) 06:13, 22 December 2022 (UTC)

On the fly I would say with subpages, i.e. SHACL/Subpagename --Chris2map (talk) 08:54, 22 December 2022 (UTC)

Web scraping specific pages of the Wiki

I'm aware at least the Infoboxes of the Wiki are web scrapped for metadata about the tags and this information can be taken from TagInfo. Could I do the same for something that's not the infoboxes, then invite people to edit the pages in the Wiki if they want to update the external release? Also, there's some way to know recent changes, so not even need to try downloading what's already cached?

My use case would be RDF reusable code snippets which cannot be automatically generated by other means plus GitHub automation to basic validation then compile the result files that would be used by ready to be used in software. For example, sense at least some version of the Elements in RDFS/OWL and other more top level reusable definitions, such part of what was proposed on Persistent_Place_Identifier, like some way to express equivalent as a search query on own database (e.g. the suggested approach from Relations_are_not_categories). That's it the use case --EmericusPetro (talk) 07:05, 22 December 2022 (UTC)

"Could I do the same for something that's not the infoboxes" yes Mateusz Konieczny (talk) 21:06, 2 January 2023 (UTC)
"then invite people to edit the pages in the Wiki if they want to update the external release" - yes, as long as you ask them to map according to OSM Wiki rules (breaking OSM Wiki to get desired effect in external tool is not welcome) Mateusz Konieczny (talk) 21:06, 2 January 2023 (UTC)
"Also, there's some way to know recent changes" - I would try parsing OSM Wiki dumps or checking api version of Special:RecentChanges Mateusz Konieczny (talk) 21:06, 2 January 2023 (UTC)
@EmericusPetro: Mateusz Konieczny (talk) 21:06, 2 January 2023 (UTC)
@Mateusz Konieczny: Great! About the "(breaking OSM Wiki to get desired effect in external tool is not welcome)" if I do draft some generic parser, based on feedback on Talk:Taginfo/Parsing_the_Wiki, I believe is better discuss ahead of time the way parsing is done and how the intermediate results are exposed (I'm thinking in document the output with JSON Schema + JSON-LD). Also, I'm less concerned with the tool or particular service, and more the conventions, so it could be ported to other programming languages --EmericusPetro (talk) 20:51, 5 January 2023 (UTC)

Just a quick update. Pretty much early draft, however I think I can generalize the idea! This means it could be used by any other kind of tooling, not just the ones related to persistent identifiers, RDF, etc. But first I need some days to decouple some parts instead of writing in a single monolithic full thing. However, is viable expose codes on <syntaxhighlight lang=""> / "<source lang="">, the wiki tables as tabular format, then both an documented JSON of what to expect of the exposed metadata, and also some sort of zip download of inferred files on any page (for tables use CSV), just by using the page title. --EmericusPetro (talk) 20:51, 5 January 2023 (UTC)

When to use what tag status in articles

Hi. Does anyone know when to use what tag status in articles? Like say someone creates an article for a tag with 3 uses that were mapped by a single person who probably also created the article, would that make the status "proposed", "in use" or something else entirely? Say an example like that is "proposed", then where's the threshold that makes a tags status change to "in use"?

As a side to that, I can't find it right now but I thought there was a discussion about this where the consensus was that a tag has to have at least a couple of hundred uses by multiple people for it to be considered "in use." Which I think is slightly excessive. Although conversely, calling a tag with single digit usage that was added by like 2 people "in use" seems tenuous at best. Especially in cases where the tag is clearly a synonym or possible tagging mistake. Anyway, I'm interested to know what other people think about it. Thanks. --Adamant1 (talk) 00:50, 14 January 2023 (UTC)

@Adamant1: have you seen Tag status page? Mateusz Konieczny (talk) 06:10, 14 January 2023 (UTC)
"thought there was a discussion about this where the consensus was that a tag has to have at least a couple of hundred uses by multiple people for it to be considered "in use." Which I think is slightly excessive." it seems fitting though in large part it depends on a tag - compare man_made=obelisk that would qualify far faster with dual_carriageway=yes where using it for few hours in a single city was enough to pass 2 000 uses and still barely qualify for "in use" to speak nothing about "de facto" Mateusz Konieczny (talk) 06:10, 14 January 2023 (UTC)

Prefix versus key sites ...

While going through the prefix stuff I found a few questions/things to solve:

  • 3.) Data items: Some data items contain a links to the Prefix page, for example in Item:Q5380 there is a link abandoned:. On the Tag:highway=abandoned page that loads data from Item:Q5380, a link will be created in the format abandoned: instead of abandoned:*. Will the code be reprogrammed for this, or is the solution to create redirect pages to a prefix for other languages?
  • 4.) Redirects: Should ES:Key:abandoned contain a redirect to the eng version of the abandoned page or should I have it deleted? It now links to the Prefix page instead of the key information. Such links to the English version of the site are created automatically even without these redirects, so I find such a redirect unnecessary and create the impression that there is a page in the appropriate language, even if it is not. -- Lenochod (talk) 20:46, 17. January 2023 (UTC)

Thanks a lot for investigating and bringing this to attention! These are things that no one foresaw in detail. I'm afraid there are some bigger tasks involved. - For ease of reference, I have allowed me to add numbers to the points. - The 1st can still be solved creating a wiki template. The others, I suspect, require intervention in the LUA modules used by Template:Description. At least my abilities are exceeded with it. Who can take on this matter? --Chris2map (talk) 17:36, 18 January 2023 (UTC)

Some success with 1. and 2.: See
Talk:Wiki - Other languages
Public-images-osm logo.svg
Aspa Herrgård Wahrendorffska stallet.jpg
DescriptionHelp translate this into British English!
Riding stables, equestrian center
Using this tag is discouraged, use building=stable instead.
Useful combinationHelp translate this into British English!
StatusHelp translate this into British English!deprecated

exclamation mark

This feature has been labeled as deprecated.Help translate this into British English! The recommended replacement is: building=stable.Help translate this into British English!
The reason may be documented in Deprecated features or in this article.Help translate this into British English! You are still free to continue to use or interpret this tag as you see fit since OpenStreetMap does not have “banned features”.Help translate this into British English!
Under no circumstances should you (semi-)automatically change “deprecated” tags to something else in the database without conforming to the automated edits code of conduct.Help translate this into British English! Any such change will be reverted.Help translate this into British English!


Public-images-osm logo.svg
Aspa Herrgård Wahrendorffska stallet.jpg
DescriptionHelp translate this into British English!
Riding stables, equestrian center
Using this tag is discouraged, use building=stable instead.
Useful combinationHelp translate this into British English!
StatusHelp translate this into British English!deprecated

exclamation mark

This feature has been labeled as deprecated.Help translate this into British English! The recommended replacement is: building=stable.Help translate this into British English!
The reason may be documented in Deprecated features or in this article.Help translate this into British English! You are still free to continue to use or interpret this tag as you see fit since OpenStreetMap does not have “banned features”.Help translate this into British English!
Under no circumstances should you (semi-)automatically change “deprecated” tags to something else in the database without conforming to the automated edits code of conduct.Help translate this into British English! Any such change will be reverted.Help translate this into British English!


Public-images-osm logo.svg
Aspa Herrgård Wahrendorffska stallet.jpg
DescriptionHelp translate this into British English!
Riding stables, equestrian center
Using this tag is discouraged, use building=stable instead.
Useful combinationHelp translate this into British English!
StatusHelp translate this into British English!deprecated

exclamation mark

This feature has been labeled as deprecated.Help translate this into British English! The recommended replacement is: building=stable.Help translate this into British English!
The reason may be documented in Deprecated features or in this article.Help translate this into British English! You are still free to continue to use or interpret this tag as you see fit since OpenStreetMap does not have “banned features”.Help translate this into British English!
Under no circumstances should you (semi-)automatically change “deprecated” tags to something else in the database without conforming to the automated edits code of conduct.Help translate this into British English! Any such change will be reverted.Help translate this into British English!

). Is it the way it should be? - It is done by adding option type=prefix to Template:Tag. For now, this is a test on my sandbox. If it works for you, we could update {{Tag}} and put "type=prefix" in {{Prefix}} so you wouldn't have to write the type=prefix in the tag link. --Chris2map (talk) 23:05, 18 January 2023 (UTC)

@Chris2map: The result looks OK, you can insert for me. -- Lenochod (talk) 13:25, 20. January 2023 (UTC)
@Aharvey:@Lyx:@Minh Nguyen:@Push-f:@Reneman:@Tigerfell:@Wynndale: Hi! Before I get started editing that heavily used template, I want to ask for double-checking the suggested changes to {{Tag}}, that I'm testing on User:Chris2map/Sandbox&oldid=2467559 to fix linking to key prefix pages named with " :* " (see discussion above) - {{#ifeq:{{{type|}}}|prefix|[[{{TagPagename|lang={{{kl|}}}|1={{{1<noinclude>|name</noinclude>}}}}}:*|{{{1<noinclude>|name</noinclude>}}}]] - Main queries: Any errors? Any performance issues? - I would welcome any feedback! --Regards, Chris2map (talk) 14:18, 20 January 2023 (UTC)
I did not spot anything. While reading I was just wondering if it would be better to name the prefix pages Prefix:a to distinguish them from the keys. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 23:12, 20 January 2023 (UTC)
ad 3) Even if I'm not happy with, we should add all redirects (Key:prefix: -> Key:prefix:*) and create those pages (with ":"), IMHO, to make sure linking works in any cases. --Chris2map (talk) 08:03, 22 January 2023 (UTC)
ad 1) and 2) {{Prefix}} Template:Prefix has been updated. --Chris2map (talk) 08:59, 19 February 2023 (UTC)

Templates stop working in page with many table lines

In this page, the state and relation templates stopped working a few days ago, on the bottom of the last table. [see] I've noticed that it's probably due to a limit per page, because if I add or remove lines, the templates appear or disappear accordingly. Is there anything I can do to correct this? --AntMadeira (talk) 17:57, 13 March 2023 (UTC)

Page is listed in Category:Pages where template include size is exceeded. It appears that there is a limit on template calls that has been reached. I don't think it has anything to do with the table. I don't know if it's possible to change the limit. The only way I can think of quickly is to substitute (insert and convert) the templates using "subst:" instead of standard including. E.g. {{subst:State|c=3|ju=4|ln=3|rl=4|fu=3}} --Chris2map (talk) 18:45, 13 March 2023 (UTC)
I tried as you suggested, but the error persists... --AntMadeira (talk) 23:15, 14 March 2023 (UTC)
It works but you have to substitute many many template calls to get space from the limit and some more lines working, because each line needs several template calls. This is truly not a solution. In addition, substituting the template:State provides ugly source code to the wiki page. – Meanwhile, I recommend splitting the page into several, e.g. one for each district. --Chris2map (talk) 17:28, 15 March 2023 (UTC)
This page is too long and too big anyway. I suggest dividing it into subpages. maro21 21:03, 19 April 2023 (UTC)

Relation vs Area strikes again

Template:ElementUsage - used in infoboxes - onRelation does not cover multipolygons (covered by onArea) but links to "general relation page which has multipolygon as the first example relation type" as pointed out in

How we should fix it? Start "non-multipolygon relation" in English and various translations?

Drop display of onArea, onRelation etc?

Something else?

Mateusz Konieczny (talk) 18:33, 26 March 2023 (UTC)

What do you mean "strikes again"? I missed the previous strike, if there was one.
I'm inclined to do nothing here. I've read the discussion but I haven't found evidence that anything is seriously broken: the . I think it confuses only those who want to be confused. Duja (talk) 07:57, 29 March 2023 (UTC)
It is a repeated confusion that is appearing again and again. Mateusz Konieczny (talk) 17:41, 30 March 2023 (UTC)
How about removing the onRelation box altogether, and/or splitting it into a separate template? Relation is a nebulous concept, with or without multipolygons included. Off the top of my head, I cannot think of (m)any tags that are applicable to both spatial map elements and non-areal relations (it's mostly either-or). But Someone(TM) should conduct an analysis how many such are out there, and I don't know a simple way to do it. Duja (talk) 10:06, 31 March 2023 (UTC)
I'm inclined to accept this discrepancy as a temporary issue that will resolve itself once we have a proper area data type. --Tordanik 07:52, 30 March 2023 (UTC)

Taginfo usage counts

Do we need taginfo usage counts in value listing? It seems for me to not be crucial info and it further overload OSM Wiki pages, makes them even more unusuable on mobile devices.

Taginfo usage counts are shown in infoboxes of specific values already and putting more weight on raw usage counts seems to not be very useful.

I would propose to remove them from value listing rather than adding them

@Cyton: who added it to

Mateusz Konieczny (talk) 17:41, 30 March 2023 (UTC)

Oh, my bad, I didn't think about the server strain. I'm still new to editing the wiki. I think I'm going to create another personal page for it and remove the infoboxes which I have added.
Cyton (talk) 09:37, 31 March 2023 (UTC)
Why does the template "Taglist|tags=bicycle_parking" only render two values and not more?
why is the Bicycle_parking template not a Taglist?
Cyton (talk) 09:44, 31 March 2023 (UTC)
Taglists have multiple issues. For example: it is not documented what is the data source (see ), there is no ability to provide custom text/images, they are build dynamically by JS what is sometimes quite laggy, random bugs on data format accepted elsewhere on wiki, once sometimes goes wrong it is unclear how their content can be fixed. Mateusz Konieczny (talk) 10:43, 31 March 2023 (UTC)
"Why does the template "Taglist|tags=bicycle_parking" only render two values and not more?" - no idea, I do not understand how Taglists work Mateusz Konieczny (talk) 10:43, 31 March 2023 (UTC)
It is less about server strain, more about overloading user with too much info at once. For most people reading tag listing is overwhelming already: adding bunch of numbers is not helping with this Mateusz Konieczny (talk) 10:43, 31 March 2023 (UTC)
"Why does the template "Taglist|tags=bicycle_parking" only render two values and not more?" - See Template:Taglist/doc: "The list will not contain all tags, but only those documented on the wiki. To be more specific: The tag page must exist and contain the Template:ValueDescription info box. This use is probably not what you want in most cases, because the list can and will change without you noticing and you might get strange tags in there you didn't want to have. So it is better to write down exactly what tags you want to have in this list." --Chris2map (talk) 15:40, 31 March 2023 (UTC)
In this case, I think the "taginfo" column can stay, because the table doesn't have that many rows. But I would remove the "element" column, because the values in the cells are the same - they refer to the key and don't differ for different values.
And to answer your question why Taglist only shows 3 values - because there are only 3 articles on the subject - see Key:bicycle_parking "Documented values: 3". maro21 21:08, 19 April 2023 (UTC)
The edit was reverted, so the thread is
? maro21 21:08, 19 April 2023 (UTC)

Rendering for buildings in infoboxes

In infoboxes for building=* tags, the building rendering is automatically shown, even though there is no link to it either in the infobox or in the data item. Example: Tag:building=church, Item:Q6034. Has anyone changed anything recently to have the rendering added automatically for every building=* tag? Where is it defined? maro21 19:01, 29 April 2023 (UTC)

@Maro21: The module that powers the templates says this particular row should fall back to the key's statement for the image. This statement on the key's item specifies that image, though I'm unsure why it's a different size than in Key:building. – Minh Nguyễn 💬 06:39, 30 April 2023 (UTC)
So if I understand correctly, this will work for each key - that is, if I add an OSM Carto image to the data item of a given key (e.g. shop), that image will automatically display in each article tag shop=something? The same situation we have with groups now. But those things you linked have been around for a long time, no one has changed them in the last year. And I remember that a year ago the rendering was not automatically displayed on the tag description pages.
So it makes me wonder why these renderings have recently appeared.
The size is smaller because there is a defined height in the infobox, and otherwise it is default size. maro21 10:26, 30 April 2023 (UTC)
I had a suspicion: Maybe the fallback doesn't do if there is a mismatch in filenaming between page value and data item with the tagkey. And since I've suppressed mismatching for "_"/" " cases, the fallback is also doing its job on those tags and keys. But I can't discover a mismatch in notation of osmcarto-rendering with Key:building. So I'm wrong, probably. --Chris2map (talk) 17:18, 4 May 2023 (UTC)

Reference group label

Template:Efn is not working as expected: the group labels are showing up raw like "[lower-alpha 1]" instead of "[a]". provides instruction on how to get that stuff to work. --Artoria2e5 (talk) 14:21, 15 May 2023 (UTC)

What do you want to do? maro21 18:36, 17 May 2023 (UTC)
@Artoria2e5: Fixed by copying over the messages in Special:PrefixIndex/MediaWiki:Cite link label group-. Thanks for the pointer! – Minh Nguyễn 💬 21:18, 27 May 2023 (UTC)

Wordmark in Vector New version

Hello, I noticed the fact that no OpenStreetMap logo appears on the header of OSM Wiki with the Vector2022 skin. Only a text "OpenStreetMap wiki" appears. I therefore propose the addition of Openstreetmap logo.svg or OpenStreetMap icon simple.svg like icon and OpenStreetMap Wiki wordmark proposal.svg like wordmark. What do you think ? Regards Manjiro5 (talk) 14:57, 17 May 2023 (UTC)

PS: The actual header without logo : OpenStreetMap Wiki header in Vector 2022.png Manjiro5 (talk) 15:00, 17 May 2023 (UTC)

I agree ! — Koreller (talk) 22:57, 18 May 2023 (UTC)
I agree, too! --Chris2map (talk) 07:35, 19 May 2023 (UTC)

This issue also affects the Minerva skin, the default skin when viewing the site in a mobile browser. Currently, you see the site name in plain text in the header.

It needs to be a horizontal, wordmark-style logo, not the square logo we've been using. A simple option would be the official OSM logo with "OpenStreetMap Wiki" to the side, similar to what's on, but it has to be a single image. (Unfortunately, this precludes any translation; I'm unsure if any languages are currently translating "OpenStreetMap Wiki" in text.)

Once we decide on a logo, we'll need to ask the sysadmin team to install it by editing the site configuration.

 – Minh Nguyễn 💬 05:24, 25 May 2023 (UTC)