From OpenStreetMap Wiki
Jump to navigation Jump to search

If you have ideas for the wiki, you can generally just do them, by editing the wiki! Big restructuring can be discussed in relation to WikiProject Cleanup, but in general we would encourage you to be bold.

If you have ideas for technical improvements to the way the wiki works, e.g. extensions we should install, you might add them here, and/or create issues in GitHub: Blacktocat.svg openstreetmap/operations/issues/. Older requests can be found in trac (raised as 'component=wiki'):

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

Sticky table headers

Hi all, trying to add support for sticky table headers (useful for large tables).

The changes are minimal and non-invasive (a couple of style rules for Common.css); more details here.

Resolved: done, thanks! Mateusz Konieczny (talk) 14:55, 10 January 2021 (UTC)

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

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 Blacktocat.svg 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)

Redirects for linking from Taginfo

The page Key:jetski:rental saw some reverts recently and that is why I would like to know if there is some common opinion about creating redirects for supporting links from taginfo to the wiki.

Background information: Taginfo searches for wiki pages with the format Key:abc or Tag:abc=def. Sometimes the second page does not exist because the tag page includes all information already or the information is trivial such as yes. Some users then create a page Key:abc=yes which redirects to Tag:abc while others dislike that and mark the page for deletion.

I would like to formulate some guideline, so that the reverting stops. Are there any objective reasons why one option might be preferable? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 15:26, 4 January 2020 (UTC)

If anyone is willing to code a fix for Taginfo issue 248 this argument goes away because Taginfo would no longer need to use documentation pages.--Andrew (talk) 17:03, 4 January 2020 (UTC)
I need to, but will be happy if someone else would tackle that. I will be happy to consult. Ping me on OSM slack (user nyurik), or can do a video chat. --Yurik (talk) 19:01, 4 January 2020 (UTC)
@Wynndale: That is even better! Are the Taginfo maintainers willing to merge such code? I am skeptical, because I emailed System-users-3.svgJoto (Jochen Topf on osm, edits, contrib, heatmap, chngset com.) on 26 November and asked him to unlock the conversation, but I never received a reply. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 17:48, 5 January 2020 (UTC)
Changing Taginfo to stop using OSM Wiki and replacing it with data items is a terrible idea. Mateusz Konieczny (talk) 08:30, 13 January 2021 (UTC)
I would say that such redirects are useful only if redirects leads to a different key Mateusz Konieczny (talk) 08:30, 13 January 2021 (UTC)

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))


I've noticed OSM Wiki uses Google reCAPTCHA which I've been almost hit with trying to create my user page. (By "almost" I mean I have Google's domains blocked so my browser cannot download the captcha)

There are automated tools specializing in solving Google's captcha (Buster captcha solver is a freely available example) and I've used some to fully automate jDownloader and similar workflows. Hence reCAPTCHA leaves a lot to be desired in fighting off automated spam.

Moreover, all such tools don't prevent reCAPTCHA's code from running, they simply automate the typing and clicking-through behavior. ReCAPTCHA's code analyzes and attempts to fingerprint your OS and computer. In effect reCAPTCHA de-anonymizes to Google the users of every site which requires its users to solve it. In addition to obvious privacy concerns, as Google is OSM's main competitor, I'd argue doing this to OSM's own contributors is unwise.

I would suggest replacing this with another captcha system, such as Wikipedia's captcha. Rostaman (talk) 03:21, 18 January 2020 (UTC)

See for some context. "I switched to FancyCaptcha for awhile and got shouted at because blind users were unable to complete the captcha.". I am unfamiliar with Wikipedia's captcha (is it usable by us?), but you may try opening a new issue there proposing such change Mateusz Konieczny (talk) 10:12, 18 January 2020 (UTC)
Yeah it seems Wikipedia's captcha has the same problem. I wonder if it could be possible to create some sort of fallback where people can choose to solve Google's captcha if they can't solve the one that doesn't have audio fallback. Rostaman (talk) 02:45, 22 January 2020 (UTC)
It is probably one of cases that are in category of "will be not fixed without someone willing to write necessary code/configuration updates, current contributors are unlikely to have time for that" Mateusz Konieczny (talk) 10:04, 22 January 2020 (UTC)

I wonder if the amount of spam would increase significantly, if we would switch off this CAPTCHA. @Rostaman: Is there any way to get the number of actions denied by reCAPTCHA? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:43, 25 January 2020 (UTC)

I don't know, I've never served reCAPTCHA on a website, only solved them. You might want to ask Google or whoever has set up reCAPTCHA on this wiki. I'd say that Wikipedia, despite using a simpler Captcha, doesn't seem to have a large problem with automated spam. They also have nofollow set for links from user pages (see ) - reading that page, this might already by in place here too since this wiki appears to use MediaWiki too. Rostaman (talk) 05:39, 27 January 2020 (UTC)

Yes, please remove the Google Captcha immediately!.--Kartenziegel (talk) 15:23, 6 February 2020 (UTC)

As a follow-up, I suggested to disable CAPTCHA and check if spam increases significantly. Blacktocat.svg openstreetmap/operations/issues/383 --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:57, 26 March 2020 (UTC)

Exclude OSM-Wikibase edits from Recent Changes

How can I exclude the Wikibase ("OSM Wikidata") from Special:RecentChanges? hideWikibase doesn't work: --Furusato (talk) 04:34, 15 February 2020 (UTC)

Hi, you can use the filters and exclude the "Item" namespace. --Dcapillae (talk) 08:40, 15 February 2020 (UTC)

Rendering sample images broken in Taglists if they include spaces or underscores

I've been about to change Template:Map_Features:aerialway and Template:Map_Features:power to taglists, but I see that the rendering samples in the taglists do not work properly. This problem is currently visible in taglists like Template:Map_Features:barrier and Template:Map_Features:military. I'm not sure if the issue is in the wiki software or in taginfo or both, but it appears we can fix this by changing the underscores to dashes instead. Geozeisig, would you be interested in trying to fix this? I know you have done a lot of work to maintain these rendering sample images. --Jeisenbe (talk) 22:37, 26 February 2020 (UTC)

Jeisenbe Can you give an example of how it is meant? I am no longer a friend of taglists because a lot of information is lost.--geozeisig (talk) 06:49, 27 February 2020 (UTC)
Well, I thought that changing the underscores to dashes would fix the problem, but now it does not appear to be working for Template:Map_Features:aerialway. Perhaps the problem is with all png files? See and --Jeisenbe (talk) 08:01, 28 February 2020 (UTC)
Thank you for finding the reason of not displayed pictures in Taginfo/Taglists. I noticed this behavior some time ago also for the historic=* table, see my question there at the discussion page: Talk:Key:historic#Taglist_rendering_pic_not_displayed_e.g._for_historic.3Dcastle_wall. Okay, i could help to fix it, but can't tell when i have time for it. By the way, i also struggle a bit with the newer Taginfo/Taglists system, because for some reason i can't see the preview (edit:"Show preview"-function button). The error message says LOADING TAG LIST... (If you do not see this tag list, you need to enable Javascript). Is there something i have to configure on my machine (Javascricpt seems activated for the used browser - firefox), or is this a general issue? Without working edit:"Show preview"-function i wouldn't want to switch to the taglist system. --MalgiK (talk) 11:03, 27 February 2020 (UTC)
Re: "The error message says LOADING TAG LIST..." - I see this sometimes when I have a bad internet connection, but usually if I hit the "preview" button again, it will show. I agree that it is annoying to rely on Javascript rather than having the table pre-rendered. Perhaps someone can fix this technically.
Interesting, i think i'm trying it when having a good enough internet connection and i can see the delayed situation while loading an "normal" article page Taglist-delay-aerialway-main-page-loading.gif, but it never shows the Taglists after hitting the "preview"-button [4]. --MalgiK (talk) 08:07, 1 March 2020 (UTC)
I do like that the descriptions and images are now the same on Map Features and on the wiki pages for each tag, with this system, and this means that they are more likely to be correct and up-to-date. --Jeisenbe (talk) 04:05, 28 February 2020 (UTC)

Query on Wikidata tag value in OSM

Hello Everybody,

I am new on this wiki. I work mostly with Wikidata.

My question is : where can I adress a query to find the object in OSM with a specific value on his Wikidata tag?

Example : This object in OSM have the tag wikidata where is indicate the value of the similar Wikidata item Q3330626.

Where can I query this wikidata value, to find by example the OSM object with Wikidata tag value Q85855578?

I know WIWOSM but I don't be able to get back the geographic coorrdinates through this interface.

Thanks a lot in advance for your help.--2le2im-bdc (talk) 06:23, 27 February 2020 (UTC)

overpass turbo is what you want. Open select wizard, enter "wikidata=value global" (for worldwide search) or "wikidata=value" (for in-view search) Mateusz Konieczny (talk) 07:21, 27 February 2020 (UTC) 07:21, 27 February 2020 (UTC)
Great!! Thanks a lot @Mateusz Konieczny: and @Geozeisig:!--2le2im-bdc (talk) 11:18, 27 February 2020 (UTC)
Resolved: answered Mateusz Konieczny (talk)

Preferences: remove option "Mark all edits minor by default"

In the Preferences for this wiki, there is an option under "Editing" to "Mark all edits minor by default". I've now seen 2 users who are rather frequent editors who have (unintentionally?) used this setting, and therefore all their major edits to pages are marked as minor. It seems to mean that this option is a bad idea: there are no wiki editors who only make minor edits 100% of the time. Is it possible to remove this option? --Jeisenbe (talk) 06:47, 13 March 2020 (UTC)

"only make minor edits 100% of the time" - and even if someone makes minor edits 99% of the time then not switching checkbox during bigger edit is still not helpful. Though I admit that I completely ignore major/minor distinction. The most problematic edits are from people willing to (deliberately or by mistake) writing incomplete/misleading edit description. Mateusz Konieczny (talk) 08:43, 13 March 2020 (UTC)
I often use this setting when I propagate a minor change on several pages (like translations or categories). Additionally, bots often make minor edits only. I also stopped using the minor edit flag as an indicator for reviewing changes. It is possible to disable the option and the English Wikipedia did this [5]. One would have to set
$wgHiddenPrefs[] = 'minordefault';
in the configuration and reset the setting for all users in the database. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:27, 14 March 2020 (UTC)

Guideline for tables

There should be some kind of guideline for when and how to use tables. Along with what fields tables should contain. Currently, tables are being created for their own sake. With a lot of fields that serve no purpose and have useless information. Articles with the indiscriminate use of tables don't load well either. Especially if the tables are in templates. For example the cuisine article always either loads extremely slowly or just time outs. Another example is the Tourism tag overview article. It takes a like 5 seconds to load, some of the example rendering icons are broken, and it freezes up when scrolling through it. So, there should be some kind of standards for labels. They don't make information any easier to find if using them just makes articles load slowly, not load at all, freeze, or break. --Adamant1 (talk) 12:44, 17 April 2020 (UTC)

@Adamant1: Are you still seeing this performance issues with tables specifically? From what I've seen so far, the major contributors to long page load time are numerous Wikimedia Commons images and overly complex templates, but I haven't seen signs that the table syntax slows down page load time, at least not on the server side. That said, large tables are notorious for slowing down page layout time in browsers, particularly Gecko-based browsers. – Minh Nguyễn 💬 23:37, 16 October 2020 (UTC)

Resolved: no response to request for additional info Mateusz Konieczny (talk)

Gadgets and Extensions for Microgrant Applications

Hi, I am Geoffrey, a member of the Microgrants Committee. We have added the Probox Template to the OSM Wiki copied from Wikimedia's Rapid Grants to be used for the microgrant applicants like this one. We would also like to add Join and Endorse buttons to the template to make it easier for the community to endorse or join they want to support. Adding the Join and Endorse buttons requires to add the Meta:AddMe page gadgets.

The Microgrant Program is starting this year, and is expected to continue every year, depending on the number of applications that come in, it means that the template and its extensions will be used on several pages. Add the buttons can also be used for endorsing other proposals like the Tagging Proposals.

We would also like to install the DynamicPageList extension that would allow us to automatically create a list of applications under the different categories ie Open, Draft, Funded, Withdrawn, Ineligible, Not Funded. Please let us know if there is an other easy way to do this that is already existing.

I would like to get your feedback and help to get these gadgets and extensions installed, if it is established that they are necessary and can be added to the OSM Wiki -- Kateregga1 (talk) 13:42, 22 April 2020 (UTC)

Requesting ban for RTFM

Due to

I am asking for a long-term or a permanent ban for RTFM.

I am considering his/her legal threats to be hilarious, and damage done by that editor was easy to fix.

But wasting time on reverts is not productive. And such legal threats may scare some other users.

I would be fine with RTFM editing wiki, as long as such problematic behavior is stopped.

Mateusz Konieczny (talk) 14:23, 30 April 2020 (UTC)

The comment with the link to not a direct legal threat (but still not acceptable behaviour anyway). It's just general legal counselling about defamation and libel. However, the comment used on User_talk:Rtfm is a legal threat and no user on this wiki should face any in personal disputes with other users. I propose to ban his account on this wiki until he revokes this threat. Nobody should "learn" that expressing and keeping up legal threats is permitted for contributors to this wiki. --Nakaner (talk) 19:48, 30 April 2020 (UTC)
Also, he repeatedly insults the intelligence of other users, calls people who ask him not to insult others whiners, and makes claims everywhere that people are just paid editors with bad intentions. Which is semi-related to the whole sabotage thing, but a different issue IMO. Really, none of his actions should be acceptable. Especially considering the warnings and recent block (that didn't seem to help). More so though due to him making legal threats about defamation while repeatedly accusing other users of things. Which is completely ridiculous and shouldn't be tolerated. Even if there is no explicit rule about it. --Adamant1 (talk) 04:59, 1 May 2020 (UTC)
  • Pinging active moderators (checked block log and deletion log): @Lyx:, @Tigerfell:. I am not entirely sure is this thread the best solution, but I have no better idea what would be preferable. Posting on mailing list/diary seems worse, tracking down admins and contacting them privately seems to not be better (maybe it would be better). I am pretty resistant to this type of harassment, but it is slowly getting irritating to me. Mateusz Konieczny (talk) 21:41, 3 May 2020 (UTC)
I have asked User:Rtfm for a one week cooling down period to allow me time to look into this. --Lyx (talk) 22:24, 3 May 2020 (UTC)
Thank you for a quick reaction. And sorry for dumping this on moderators, hopefully I was not misrepresenting the situation. I will also avoid engaging this user (no posting further complaints on their talk page, I will try to avoid reverting their edits for now etc). Mateusz Konieczny (talk) 22:44, 3 May 2020 (UTC)
@Lyx: - sorry for bothering you, but what is the status of this thing? Mateusz Konieczny (talk) 10:40, 24 May 2020 (UTC)
Sorry for being so slow with this. A short status update: I have received comments from some people involved in this dispute as well as one of the other admins, and started to check the text on and history of the pages involved. However, I am not finished yet getting a complete picture of the situation and the events leading to it. As far as I can see all people involved acted responsible in the meantime and did not attack any of the others, thank you all for this. I know that I already needed far more time than I initially expected, but I hope you can still grant me some more time. --Lyx (talk) 19:33, 24 May 2020 (UTC)
I am perfectly fine with waiting longer, I just wanted to check is it progressing at all. I understand that it is tricky to do and the most irritating kind of drudgery for multiple reasons Mateusz Konieczny (talk) 21:23, 24 May 2020 (UTC)
@Lyx: ? Mateusz Konieczny (talk) 22:05, 23 June 2020 (UTC)
What do you think about (mass) edits like this ? user:rtfm Rtfm (talk) 20:06, 5 June 2020 (UTC)
@Rtfm: please keep this discussion focused on wiki issues. In case of mapping issues, please contact DWG instead. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 12:06, 6 June 2020 (UTC)

I do not side with the notion of the ban. I shall give a thumbs up on Mateusz Konieczny's most recent offer of a compliment to a OSM editor as of late. No further comments. EnBoldenTexts (talk) 06:41, 24 June 2020 (UTC)

Bot request to set page language

I would like to have the page content language of pages beginning with Ro:Moldova/ and Ro:Romania/ set to Romanian. This means they still display in Romanian if the {{Place}} template is changed to use the page content language. --Andrew (talk) 06:10, 13 May 2020 (UTC)

Request deletion of access=use_sidepath

access=use_sidepath exists as a redirect to bicycle=use_sidepath, but use_sidepath should not be used directly with access=* (only with specific modes of transportations such as bicycle=use_sidepath). The existence of that page makes sites like TagInfo mark access=use_sidepath as wiki-documented, which is not desirable. Can it be removed? I created Compulsory use of parallel way to replace it. JeroenHoek (talk) 16:52, 29 May 2020 (UTC)

Note that "Wiki-documented" does not mean "should be used". Many tags are wiki-documented as deprecated on their own page (for example with explanation and alternatives)- see for example contents of Mateusz Konieczny (talk) 19:09, 29 May 2020 (UTC)
In my experience it seems better to have an article for a tag and clearly document it a depreciated if that's the case then not. Especially if it's between documenting that it's depreciated versus having a forward. Since forwards don't loudly tell people that the recommendation is to not use the tag. Plus, with forwards there's always the risk that eventually someone who wants to use tag (or force it on others) will create the article, treat the tag as legitimate, and then edit war etc anyone attempts to say otherwise. In other words, in some cases it's much harder to depreciate a tag after the article is created when it was originally a forward then it is to just skip the forward and document it that way in the first place. Plus, it works better with Taginfo that way also. --Adamant1 (talk) 12:02, 5 June 2020 (UTC)
I've updated the page to clearly state its status. There was only one way in the database that used it, and that was clearly a tagging error. This should prevent anyone from seeing it as a valid tag/value combination. JeroenHoek (talk) 06:42, 6 June 2020 (UTC)

Followup on CAPTCHA

I've recently found out that Cloudflare has its own CAPTCHA service called hCaptcha. It's not tied into Google's surveillance network, it doesn't discriminate against non-Chrome users, it has some kind of token pass system for visually-impaired and/or privacy-positive users, and it's even currently paying webmasters for completed captchas (Google doesn't reimburse its clients for making their users do free work for its AI program). Might not be the best alternative in regards to privacy (since it still relies on a large company) but arguably better than Google. Rostaman (talk) 15:44, 30 May 2020 (UTC)

I'm surprised there isn't a viable open source non-commercial CAPTCHA system out there that could be adopted. When I randomly looked into it a while back it seemed like all the opensource options still sent information to some random server. Maybe there's one I'm not aware of though that could be used by the wiki. As I think any commercial one, Google or not, will probably compromise privacy somehow and therefore be semi-problematic. The only way around it would be to go with an open source one where the information sharing can be turned off or to create one just for OSM. --Adamant1 (talk) 11:52, 5 June 2020 (UTC)
I agree 100%. However the last time I came here with this question the message was that CAPTCHA is necessary and Google's will remain in use because nothing else satisfactory was suggested. That's why I suggest switching to Cloudflare's for the time being until a privacy-friendly software is found, since Cloudflare is a lesser evil than Google. Rostaman (talk) 13:10, 5 June 2020 (UTC)
See also --Andrew (talk) 17:19, 5 June 2020 (UTC)
Google's Captcha is especially vicious because it punishes you for not having a Google account, deleting cookies or using Tor.
If you really want to defeat the SEO spam (NEW: use Cyrillic to fool the admins) you should just demand an OSM account with > 10 map edits as requirement for a Wiki account.--Tito (talk) 20:56, 5 June 2020 (UTC)
I don't think the wiki and main site are connected in way that would allow for the wiki to be able to tell if a user has 10 map edits. As far as I know, they are completely different logins etc. Not that they couldn't be integrated somehow to get around it. But a lot of higher up OSM people that should be able to edit the wiki lack map edits but are extremely active with the organization in other areas. Same for developers. So, arbitrary map edits as a qualifier could be kind of iffy. Although, 10 is a low bar, but it might be low enough for scammers to just map 10 objects then spam away. Which might slow them down but wouldn't stop them. Not that there aren't ways around CAPTCHA systems either though. --Adamant1 (talk) 04:06, 6 June 2020 (UTC)
Thanks for linking the issue @Andrew:. @others if you want to get in touch with the administrators to initiate a change, I suggest to comment on the GitHub issues. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 11:26, 6 June 2020 (UTC)

Request for code review

After rationalising {{StatusLang}}, statuses whose translations into the language of the page are missing are no longer highlighted like thisHelp translate this into English!. I have written an extra routine, getTranslation, to do what StatusLang needs including wrapping English text with {{TranslateThis}} when there is nothing in the language of the page. I would appreciate any comments. --Andrew (talk) 11:11, 6 September 2020 (UTC)

Wikidata site for |group=advertising

I created a missing wiki (wikidata) item for the Advertising group, but it doesn't appear, for example, while editing an Key:advertising, does not display with an entry for entities. Can anyone see where the mistake is? lenochod 9:15, 6 October 2020

  • It seems you created a duplicate. The item already exists at Item:Q54. Pizzaiolo (talk) 23:21, 17 October 2020 (UTC)
Resolved: appears to be answered Mateusz Konieczny (talk) 14:39, 10 January 2021 (UTC)

Discrepancies in wiki articles: can this tag be used on node? way? area? relation?

Hi everyone,

I found some discrepancies between articles. For example, in the article highway=footway, we can see in the infobox (on right) in section Used on these elements, that this tag can be used only on ways and areas. But on the other language pages (ex: FR:Tag:highway=footway), we can see that this tag can only be used on ways and not on areas. And we have the same issue on the highway=* page in the table listing all values for this tag.

And I'm pretty sure there are a lot of issues like this one.

So either we (I) will need to check every articles in every languages (very long task!) or I can create a bot.

So I want my bot to check for those issues and 'print' a report. So a regular user can try to fix those issues. I never created a bot yet, maybe I will use Pywikibot. Does anybody know if this kind of bot work on this wiki? Also, I may want to use Toolforge to run my bot, but I don't know if Toolforge can target this wiki (a wiki outside wikimedia fundation), any ideas?

Have a nide day. --Binnette (talk) 08:54, 9 October 2020 (UTC)

Ok, so it's seems that we can simply remove the parameters "onNode, onWay, onArea and onRelation" to get the 'fallback' values defined here Item:Q5015 in "use on nodes", "use on ways", "use on areas" and "use on relations". (The job is done by the module Module:DescriptionFromDataItem.)
So I'm just gonna edit highway=footway and remove the 4 parameters "onNode, onWay, onArea and onRelation".
Anybody is against my solution? --Binnette (talk) 11:37, 9 October 2020 (UTC)
BTW, we may consider to remove those 4 parameters for all tags wiki articles. So we will may be need a bot... --Binnette (talk) 11:49, 9 October 2020 (UTC)
It’s also worth checking while you’re there whether anything is in the data item is language-specific (images are not so bad but check the rest). --Andrew (talk) 20:55, 9 October 2020 (UTC)
If you delete the VD parameters ("onNode, onWay, onArea and onRelation") you will loose the taginfo displaying compatibility :-( , see on this table: --MalgiK (talk) 21:56, 9 October 2020 (UTC)
Please don't delete the parameters from the actual wiki pages. I also think that a bot is the incorrect way to do this. The right way is to check how each tag is actually being used (by looking at taginfo and overpass-turbo) and make sure the description in the wiki matches how the tag is used by most mappers. --Jeisenbe (talk)
Please don't delete any parameters at all. It is fine to edit them, but I am not OK at all with deleting such content from OSM Wiki pages and relying on this data items (there was a big discussion about this already). Note that for translation in a given language it is possible that there is agreement to give up on maintaining this and use unreliable data items. Mateusz Konieczny (talk) 08:15, 10 October 2020 (UTC)
Discussion was on this very page, see Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information Mateusz Konieczny (talk) 08:26, 10 October 2020 (UTC)
"So I want my bot to check for those issues and 'print' a report. So a regular user can try to fix those issues. " - it exists already, see list of mismatches at Mateusz Konieczny (talk) 08:18, 10 October 2020 (UTC)
For example (I am not using this as in 99+% cases either translations or data item is wrong - and I do not care about data items and I edit only Polish translation, and even mismatches between PL and data items are generally data item mistakes) Mateusz Konieczny (talk) 08:20, 10 October 2020 (UTC)
@Binnette: I am not yet comparing between languages, but I nearly wrote such bot myself. See User:Mateusz Konieczny/TODO for typical output, code is at If you are interested specifically in log about conflicts between English and French Wiki entries (or maybe French OSM Wiki vs Data items conflicts) I can generate something in format that you want Mateusz Konieczny (talk) 14:43, 10 January 2021 (UTC)

Taginfo placeholders for undocumented tags

I modified the following interface messages in English to embed {{Taginfo}} about the key or tag as a placeholder for prose documentation:

It isn't the prettiest change, but the idea is to reduce reader confusion when encountering a tag that lacks its own page, despite potentially being in wide use, even documented elsewhere on the wiki as part of a broader tagging scheme. Ideally, such tags would have their own pages or at least redirects, but taginfo can serve as a stopgap in the meantime. The taginfo tag statistics box is a mainstay on standard key and tag description pages, so it should be familiar to mappers even without explanatory text.

These three messages are some of the most frequently customized messages among MediaWiki installations. Typically, administrators customize them to more closely tie a wiki to companion websites or make the wiki more user-friendly in general. For example, MediaWiki:Noarticletext would be an ideal place to link to or a Requested articles page, while MediaWiki:Newarticletext could link to suggestions for writing a good tag description page or offer buttons to prefill standard templates. At the same time, I personally prefer somewhat utilitarian "not found" messages, which load quickly and don't take up too much space in the visual editor's flyout panel. Does anyone have suggestions for further customizing these messages?

Unfortunately, these customizations only take effect when your interface language is set to English. I've made similar modifications to the Spanish and Vietnamese translations of this message at e.g. MediaWiki:Noarticletext/es and MediaWiki:Noarticletext/vi and can do the same in other languages if desired.

 – Minh Nguyễn 💬 23:57, 16 October 2020 (UTC)

Unfortunately the taginfo box looks quite strange when the visual editor box is shown, at least in my browser. It is off to the right side but has no white space between the text to it's left, but then there is a large gap below to the left. And the label like "key=value" is not included in the box outline, so it looks like odd text on the page rather than part of the taginfo box.
I think this change will cause more confusion than benefit. If the taginfo box could be updated to show something like "key=value at taginfo" instead of "taginfo [More...]" that would help some, but it will still look odd. --Jeisenbe (talk) 08:04, 17 October 2020 (UTC)
Yeah, floating the box to the right isn’t great in the visual editor. I had originally floated it to minimize vertical jumping in case the box takes a little too long to load. The caption is part of {{Taginfo wrapper}}, which was originally intended for a table of these boxes that could get repetitive. We can make a different wrapper that calls out taginfo explicitly. Another option would be to use the |link = parameter in {{Taginfo}} to display just a link rather than the whole box. Maybe that’s best for MediaWiki:Newarticletext, which has this layout issue in the visual editor. – Minh Nguyễn 💬 16:42, 17 October 2020 (UTC)
I changed MediaWiki:Newarticletext so that the taginfo box no longer floats to the right. – Minh Nguyễn 💬 20:01, 17 October 2020 (UTC)
Another problem: this box is being added to pages like Talk:Tag:railway=yard before they are created, even though this is a talk page, not a tag or key page. Can you fix that? --Jeisenbe (talk) 17:43, 17 October 2020 (UTC)
Fixed, thanks for spotting that. – Minh Nguyễn 💬 20:01, 17 October 2020 (UTC)
Useful improvement, thanks! Pizzaiolo (talk) 23:22, 17 October 2020 (UTC)
It is very useful, thanks! Mateusz Konieczny (talk) 14:43, 10 January 2021 (UTC)

Redesign of page not found message

As a followup to Talk:Wiki#Taginfo placeholders for undocumented tags, I've started a redesign of MediaWiki:Noarticletext at Template:Noarticletext/sandbox based on w:Template:No article text. Here are the main changes:

  • A modicum of styling distinguishes the message from a very short page, so users familiar with the wiki will immediately recognize the message.
  • The message differs slightly depending on the namespace and also for keys and tags.
  • There are links to both taginfo and a tool to look up the associated data item without having to fiddle with Special:Search's advanced options.
  • For Key: and Tag: titles, clicking "Create this page" preloads some boilerplate with instructions for creating the page. There's a different boilerplate for keys versus values.

This is a work in progress:

  • MediaWiki:Newarticletext should be redesigned at the same time. It might feature a button to optionally load the boilerplate, as in User:Minh Nguyen/preload. It also needs to fit inside the narrower flyout panel in the visual editor.
  • For now, the redesigned message and boilerplates are all in English.
  • When the boilerplate is loaded, we should replace MediaWiki:Noarticletext with instructions for working with the boilerplate. (For example, when the visual editor is enabled, you'd type below each comment, optionally deleting the comment.)

Try it out, entering a variety of page titles to see how the message adjusts to different scenarios.

 – Minh Nguyễn 💬 23:53, 17 October 2020 (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 admin_centre and 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?

Data item corruption in recent changes

Data item edits are appearing as Special:Badtitle/NS120:Q5020 in recent changes and the watchlist at the moment. --Andrew (talk) 09:14, 3 November 2020 (UTC)

@Wynndale: The Wikibase extension had to be disabled briefly while investigating breakage of JavaScript throughout the site. [6] The data item changes look normal again to me; has it gone back to normal for you too? – Minh Nguyễn 💬 21:50, 3 November 2020 (UTC)
Resolved: marking as solved Mateusz Konieczny (talk) 14:44, 10 January 2021 (UTC)

Modify the osm wiki media software to get instant access (focus) to search box after opening the main page

See title "Modify the osm wiki media software to get instant access (focus) to search box after opening main page".
For better understanding please compare to wikipedia main page: Go to then the centered search box is in focus (the cursor is blinking there) and you are able to instant type in your preferred search string, same behavior would be nice for :-) . Or and even for the sub-pages, e.g. --MalgiK (talk) 04:50, 9 November 2020 (UTC)

@MalgiK: The multilingual portal automatically focuses the search box because it's the focal point of the UI. The downside is that the arrow keys don't initially scroll the page; you have to tab out of the search box first. Since the search box is off to the side and easy to miss, stealing focus this way isn't a great usability tradeoff.

Over on the Vietnamese Wiktionary, I wrote a simple gadget, on by default, that automatically focuses the search box when you start typing, but the initial focus is still on the overall page for things like scrolling. I think the gadget makes the most sense on wikis where search is the main way to navigate – in fact, that wiki's front page puts the search box front and center – but less sense on wikis where you spend significant time on an individual article.

I installed the gadget on this wiki, off by default, so that you can enable it in Special:Preferences#mw-prefsection-gadgets if you like accessing the search bar this way: check the "Automatically focus the search box when typing outside a textbox" checkbox.

 – Minh Nguyễn 💬 07:14, 9 November 2020 (UTC)

@Minh Nguyen: Thanks for detailed long answers. I agree the situation on the wikipedia main page is a bit different compared to our osm wiki main page. In this case I would be happy, if the osm wiki main page would have a similar design, or even at least the search box in the center and the other things around :-) Cool, i tested your/this gadget. For an older browser i use, it works not 100% well, the focus is actually send to the box, but the first letter appears twice in the box. However for the Firefox browser it works as expected. Then i was trying to write you this response by using the wiki source code editor (not the visual one) and the focus was also moved from the edit box to the search box when i did start typing. So i switched off the gadget now to be able for writing you. So the gadget isn't usable if a person who wants to use the wiki for searching pages and editing pages one after another. Any additional hint to solve this? --MalgiK (talk) 07:54, 9 November 2020 (UTC)
Yes, I was afraid the gadget wouldn't quite work here – another reason I left it off by default for now. I wrote the gadget back in 2011; both the wiki and browsers have changed quite a lot since then. Are you using the syntax highlighting option in the source code editor via the Syntax highlighting button? That editing surface is similar to the visual editor, which I haven't tested yet. (As it happens, the Vietnamese Wiktionary steers editors away from the visual editor, because each entry needs to follow a rigid, template-laden format.) I'll see if I can find some time to look into it again, but key handling is not my favorite aspect of scripting. ;^) In the meantime, hover over the search box to see a tooltip that includes the shortcut key for focusing the search box. (It depends on your operating system and potentially a browser setting.) – Minh Nguyễn 💬 08:20, 9 November 2020 (UTC)
@Minh Nguyen: Thanks a lot for additional information in this regard. Switching off the syntax highlighting option actually helps and hovering the mouse over the search-box shows key combination ALT-SHIFT-F on my machine, which also works. So it seems there are some workarounds, but i think it still would be interesting to get a central located search box on the main osm wiki page ( which has the focus for text input similar to wikipedia main page ( If there is a todo(which)-list for the osm wiki, i would appreciate to put this request on this list. --MalgiK (talk) 10:18, 17 November 2020 (UTC)

Meaning of "de facto" versus "in use" for keys

I recently documented the tag related_law=*, and after this subsequent edit, I am confused about the difference between status=de facto and status=in use. The documentation at Template:ValueDescription and Template:KeyDescription says:

  • de facto: the tag is in widespread use, but no formal proposal process has taken place
  • in use: the feature is in use

I am not sure how to interpret this difference. I was operating under the impression that in use was the "more adopted" descriptor, but apparently I have that backwards. If so, I propose that the description of in use be clarified to say:

  • in use: the feature has some use, but it is not widespread, and no formal proposal process has taken place.

--ZeLonewolf (talk) 17:31, 14 November 2020 (UTC)

You are correct that "de facto" is considered to be a sign of a "better" tag, in the sense that it has reached widespread use. The tag "in use" has a very wide range of meaning. It can be a rare tag which has only been used a few times, but which is being continually used by some mappers, or it can be a common tag which has been used thousands of times, but there is another tag that means the same thing. I will change the status to "de facto" for tags which have been used frequently, and when there is no other common tag which means the same thing.
The suggested text for "in use" won't work, unfortunately, because an "in use" tag could actually have had a proposal which was abandoned or rejected, but they are still being used anyway. And an "in use" tag can be pretty widespread. Unfortunately there isn't a very clear distinction. --Jeisenbe (talk) 18:17, 14 November 2020 (UTC)
If someone made a proposal to adopt a "de facto" tag, and that proposal was defeated with say 70% approval, would that tag still be "de facto"? Or would it change to "in use" or "proposed" or "rejected"? It seems to me that "de facto" is really just describing widespread (in numbers, and in geography) adoption, and "in use" is describing less-than-widespread adoption. And, both of these have not been approved by the proposal process, regardless of the proposal status. I feel that something more is needed to spell out the meaning of "in use", because if I was confused as a native English speaker, surely others will be as well. --ZeLonewolf (talk) 18:31, 14 November 2020 (UTC)
Re: "If someone made a proposal to adopt a "de facto" tag..." - I'm unaware of this every happening. It's not necessary to approve tags which are already the "de facto" standard.
Re: "something more is needed to spell out the meaning of "in use"" - the status is not very specific. It just means that it is being used. It's sort of a catch-all for tags which lack a more specific reason for having been documented in the wiki. --Jeisenbe (talk) 20:49, 14 November 2020 (UTC)
"It seems to me that "de facto" is really just describing widespread (in numbers, and in geography) adoption, and "in use" is describing less-than-widespread adoption." - I would agree with such summary Mateusz Konieczny (talk) 21:22, 14 November 2020 (UTC)
I just found the page Approval status which apparently explains this, so I'm leaving that link here for future mappers that encounter this discussion. --ZeLonewolf (talk) 22:12, 14 November 2020 (UTC)
Right, I forgot about that page. The relevant section (which I wrote a year ago after researching this issue) is: Approval_status#.22In_use.22_status
"in use status has a wide range of meaning. These tags have not been voted on and discussed like approved features and are not as widely used as de facto tags, but may still be the most common existing tag for a feature. Only a small percentage of in use tags have been added to the list of Map Features.
  • "All in use features and attributes are currently being added to new features by mappers, but have not been approved or used so widely to become de facto."
  • "Some feature and attribute tags with in use status are fairly widely used, but are too new or not yet common enough to be tagged as de facto. However, they may change to de facto after another year or two of frequent use.
  • "Some in use tags are very common, but somewhat debated. There may be another in use tag with a similar meaning, or the tag may be used for several different features with a similar name.
  • "Some in use tags may be only used in one country or by a small number of mappers.
  • "Some in use tags were rejected when proposed, but are still being used."
Hopefully that is somewhat helpful. --Jeisenbe (talk) 00:17, 16 November 2020 (UTC)
Yes, this is helpful and a good summary. I updated the documentation on Template:KeyDescription and Template:ValueDescription to link to that description. --ZeLonewolf (talk) 02:42, 16 November 2020 (UTC)
Resolved: documentation was updated, great! Mateusz Konieczny (talk) 14:45, 10 January 2021 (UTC)

"European Heritage Label" and "Historic Sites and Monuments in Antarctica"

Hi all, those two Heritage Registration Organisations seems absent from the heritage=* wiki page :

1. European Heritage Label (European commission website)

2. Historic Sites and Monuments in Antarctica (see latest list)

Both have each less than one hundred entries as of November 2020. Do you think they should be added on the wiki page? If yes, should they be categorized as "international", and which level should be used for heritage=*? -- FoeNyx (talk) 21:43, 14 November 2020 (UTC)

"Do you think they should be added on the wiki page?" it seems to me that answer is yes, but I am not familiar with the topic. Feel free to add them if you know that it would improve the page! In general, documenting used tags is welcomed Mateusz Konieczny (talk) 11:32, 15 November 2020 (UTC)
"European Heritage Label" - it seems that it would apply to some objects protected by national organizations, not sure how such cases are handled Mateusz Konieczny (talk) 11:34, 15 November 2020 (UTC)
Isn't that already an eventuality with unesco world heritage? (an overpass query “heritage~/;/” yields several results in this case in Northern Europe; for example : way 332352664); I guess, it would probably works with a third values heritage:operator=whc;ehl;national_org, heritage=1;ehl_level;national_org_level, and then specific tags for each operator like whc:inscription_date=year, ehl:inscription_date=year, national_org:inscription_date=year (...) --FoeNyx (talk) 22:53, 15 November 2020 (UTC)

I added them into the wiki page, thank you for the feedback. --FoeNyx (talk) 14:21, 22 November 2020 (UTC)

Resolved: seems solved Mateusz Konieczny (talk) 08:24, 13 January 2021 (UTC)

Template:Languages for User profile

Can Template:Languages be used for user accounts? For example, FR:User:Livewire74 / User:Livewire74. Lenochod (talk) 13:53, 16 November 2020 (UTC)

Yes, but the correct name of the French page would be User:FR:Livewire74. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:03, 4 December 2020 (UTC)
Resolved: answered Mateusz Konieczny (talk) 08:24, 13 January 2021 (UTC)

WIWOSM having major errors

WIWOSM seems to be having some major errors, with a 2.8 GB error.log file. Please refer to this discussion on Wikipedia. Some help would certainly be appreciated. Sdkb (talk) 21:17, 3 December 2020 (UTC)

Discussion was moved to where it is not present anymore. @Sdkb: Mateusz Konieczny (talk) 14:46, 10 January 2021 (UTC)
Resolved: anyone who wanted to help this specific user of OSM data already did it, linked discussion is now inactive Mateusz Konieczny (talk) 08:25, 13 January 2021 (UTC)

Unconfirmed users that want to upload images to the wiki


In the forum, there were two cases ([7], [8]) of users that wanted to upload images, but they are not in the Autoconfirmed user group. Wikipedia seems to have a mechanism to grand "confirmation" to those users manually. It looks like it is based on administrator's judgement, there seems to be no formal criteria, because everyone can get the permissions anyway. Do you think it would be helpful if there were a similar system in this wiki? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 14:06, 9 December 2020 (UTC)

This comes up relatively often, and I do think the inability to upload images is a little confusing and off-putting for new users. So anything that reduces this effect is welcome. Is the consensus that that restriction of image uploads to autoconfirmed users is still necessary? --Tordanik 15:58, 19 December 2020 (UTC)
We can try changing settings - in the worst case we may switch back and making OSM Wiki more welcoming is a good idea. Mateusz Konieczny (talk) 21:23, 19 December 2020 (UTC)
Sounds good to me.--Jeisenbe (talk) 23:18, 19 December 2020 (UTC)
Thanks for the answers. I started a thread at Blacktocat.svg openstreetmap/operations/issues/488 to get replies from the system administrators. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 17:47, 22 December 2020 (UTC)
And thanks to Tigerfell for making Mateusz Konieczny (talk) 14:47, 10 January 2021 (UTC)

New Taginfo Replacement

I've always been annoyed with the following limitations of the Template:taginfo boxes:

  • Awkward extra padding that you can't get rid of (due to IFRAME implementation)
  • Doesn't include the total count of nodes+ways+relations
  • Doesn't list the name of the tag in the taginfo box
  • Sometimes doesn't load

I've built a proposed replacement with the help of @Minh Nguyen: based on AJAX which fixes the issues above. It is currently installable as a user script for testing but my hope is that we could install it as a gadget. The new template is called {{taginfo2}}.

Screenshots and local-user install instructions can be found here: User:ZeLonewolf/TaginfoTest. --ZeLonewolf (talk) 01:34, 3 January 2021 (UTC)

The limitations above have also frustrated me and others over the years, so this replacement is an encouraging development. {{Taginfo wrapper}} was only a partial workaround; this reimplementation goes much further. I'd also add that {{Taginfo2}} is easily localizable (with the help of an administrator), unlike the extension-based {{Taginfo}} template, and it probably won't be difficult to add taginfo to data item pages where they'd also be useful.

I'd like to hear others' feedback about the overall concept before installing the user script as a gadget. This new implementation would only be useful if we install it as a gadget and enable it by default. I also left a code review over at Template talk:Taginfo2, where we can continue polishing the technical details.

 – Minh Nguyễn 💬 07:00, 3 January 2021 (UTC)

Is it having the same performance? Is it increasing load on taginfo servers? Mateusz Konieczny (talk) 11:54, 3 January 2021 (UTC)
I re-loaded the page a bunch of times and the performance seems basically the same. Sometimes the AJAX version loads first, and sometimes the IFRAME version loads first. I measured it in Google Chrome and I'm seeing around 200-300ms load times from the US East Coast for the first 3-4 boxes on a page and something like 100ms per box after that. That's just ballparking it from numbers in the network debugger in Chrome. The tag box makes 2 parallel calls to taginfo, and the relation box makes 3 calls. The current {{taginfo}} template+php makes a single call to the taginfo embed API. However, I am not sure how "heavy" the embed API is compared to the stats API calls. --ZeLonewolf (talk) 04:07, 4 January 2021 (UTC)
I opened (to avoid accidental DDOS) Mateusz Konieczny (talk) 08:24, 4 January 2021 (UTC)
The solution with the IFRAME was always a bit wonky. When I built this years ago, it was the only thing we could get to work. I don't remember the details, but I believe it was too complicated then to add extra Javascript to MediaWiki or something like that. I think the new solution is much better from a design-perspective. Some points on this: 1. Having two solutions for the same thing isn't good. So the end goal should be to get rid of the "embed" stuff. Of course it will take some time, but if you start it, you should also push this through. I would also argue that a fallback for when Javascript isn't available isn't needed in this day and age. If it isn't available the box simply isn't there or empty, that's good enough. 2) I don't like the template name "taginfo2", I am sure we can come up with something better. :-) 3) There will be some extra load on the taginfo server, but I don't think this is a problem. The "expensive" part of the processing is the database lookups and they are very similar in both cases, just spread out over more http calls. To reduce load even further (and make the Javascript simpler) we can certainly discuss adding more fields to existing API calls or even adding new API calls. If you want to pursue this, please open issues on with your ideas what would be needed or helpful for this use case. -- Joto (talk) 08:54, 4 January 2021 (UTC)

@Joto: I think the plan is to overwrite {{Taginfo}} with the implementation in {{Taginfo2}} once we're happy with it. (For future rewrites of templates, we can use subpages like {{Taginfo/sandbox}} for clarity.) If there isn't a strong desire to maintain feature parity with JavaScript disabled (or in older browsers where MediaWiki refuses to load JavaScript), then the fallback can be a simple link to taginfo.

Unfortunately, {{Taginfo}} is not nearly the only use of the embed: the <osmtaginfo> parser hook is directly used on 480 different pages, so it'll take a bit of elbow grease to completely transition to the overwritten {{Taginfo}}. At a glance, most direct usage seems to be either for value lists that predate {{Taglist}} or for custom tag comparison tables, which ZeLonewolf is also working on improving.

Thanks for being open to extending the API. I'm excited by the opportunities for taginfo-wiki integration that this gadget will unblock.

 – Minh Nguyễn 💬 10:28, 4 January 2021 (UTC)

I would be more than happy to drop no-javascript fallbacks if there is not a need for it. It would certainly simplify the code. --ZeLonewolf (talk) 12:52, 4 January 2021 (UTC)
For tags it's better but for relations worse. I prefer the previous version for relations because it's clear what these numbers mean.
4 511 208 relations
24 535 675 members
These icons for me are not understandable.
Resolved: Relation/member text is now implemented --ZeLonewolf (talk) 20:34, 9 January 2021 (UTC)
And, if it's localizable, you must remember about decimal separators which are different in different languages. These have to be translatable as well. If it's not possible to change it, you should use space instead of comma. maro21 18:33, 4 January 2021 (UTC)
@Maro21: For consistency with the localized messages, the current implementation does format numbers according to the current interface language, which you can set using the link at the language selector at the top of every page or in Special:Preferences. For example, here's User:ZeLonewolf/TaginfoTest in Vietnamese ("352.090.855" and "81,66%"), French ("352 090 855" and "81,66 %"), and Hindi ("३५,२०,९०,८५५" and "८१%"). – Minh Nguyễn 💬 08:53, 6 January 2021 (UTC)
Resolved: localized numbers and percentages are implemented --ZeLonewolf (talk) 20:34, 9 January 2021 (UTC)
  • I feel that old "[More...]" was quite nice and it should be not missing from new one Mateusz Konieczny (talk) 21:14, 4 January 2021 (UTC)
    @Mateusz Konieczny: I suggested adding the "Powered by taginfo" attribution line to provide an explicit link to taginfo, and the links at the top go to the key/tag/relation page at taginfo. However, a user could conceivably assume those links go to the wiki page, since that's the convention everywhere else {{Tag}} is used. So maybe we can change the attribution line to "More details at taginfo" and link the whole footer to the tag page instead of the taginfo home page. Does that sound better? – Minh Nguyễn 💬 09:15, 6 January 2021 (UTC)
    Re: ""More details at taginfo" and link the whole footer to the tag page instead of the taginfo home page" - that sounds like a good idea. --Jeisenbe (talk) 05:27, 7 January 2021 (UTC)
Interesting ideas, could we use an additional separator line for cases with tagLink=yes Taginfo2 3.png --MalgiK (talk) 23:20, 4 January 2021 (UTC)
Resolved: Footer and UI have been updated with both suggestions. --ZeLonewolf (talk) 20:34, 9 January 2021 (UTC)

How to translate the interface?

Where can I translate the interface of this Wiki into my language? I mean the menu on the left. My language is Polish and this menu is 50% Polish and 50% English:

pl:    Strona główna
pl:    Mapa
en:    Map Features
en:    Contributors
pl:    Pomoc
en:    Blogs
pl:    Sklepik
en:    Donations
en:    Wiki discussion
pl:    Ostatnie zmiany

maro21 15:20, 5 January 2021 (UTC)

Please file a request at MediaWiki talk:Sidebar and provide the translations. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 18:08, 5 January 2021 (UTC)

Resolved: answered, added to Wiki_Translation#Interface Mateusz Konieczny (talk) 08:28, 13 January 2021 (UTC)

Add Structured Discussions (Flow) Extension

Editing talk pages is hard for new/inexperienced users.

This can be especially frustrating/limiting when wanting to comment on a Proposal being proposed.

Adding the Structured Discussions extension provides a simple interface that allows users to respond, create, resolve, etc. topics easily.

The WikiMedia Talk Pages Project is being worked on but it doesn't look like it's available for install. Converting to this should also be a priority when it becomes available.

—Preceding unsigned comment added by Lectrician1 (talkcontribs) 00:20, 7 January 2021‎ (UTC)

If any of these tools can save us from figuring out the right combination of :::*::*:*:: to preface a comment with, then I'm sold! :-D My only concern with Flow is that it seems to be in maintenance mode as the Wikimedia Foundation has refocused its efforts on more incremental talk page improvements. My impression is that Flow isn't a particularly straightforward extension, since it changes the content model of a page irreversibly and introduces new namespaces. That said, it's a much more polished system than LiquidThreads, which is still annoyingly relying on. So if it does adapt well to a non-Wikimedia wiki, then it would make integral OSM processes like the tag proposal process more accessible to the bulk of the OSM community. – Minh Nguyễn 💬 02:26, 7 January 2021 (UTC)
(1) what would be import plan for old talk pages? Mateusz Konieczny (talk) 10:02, 11 January 2021 (UTC)
(2) is there a working export from StructuredDiscussions to standard talk pages if development on it stops? Mateusz Konieczny (talk) 10:02, 11 January 2021 (UTC)

Add CategoryWatch Extension

"The CategoryWatch extension extends watchlist functionality to include notification about membership changes of watched categories."

This would be extremely helpful to users:

  • Who want to be notified when a Proposal is added to one of the Proposals_by_status Categories. A major convenience would be for users that don't want to subscribe to the Tagging Mailing list but still want to be notified when proposals become open to voting.
  • Who monitor a Place Wikiproject's categories
  • etc.

—Preceding unsigned comment added by Lectrician1 (talkcontribs) 00:29, 7 January 2021‎ (UTC)

I second this. Would be very useful to me, who generally avoids the mailing lists. --GoodClover (talk)
+1 if this extension is not introducing some huge complexity Mateusz Konieczny (talk) 14:54, 10 January 2021 (UTC)
If I'm not mistaken I've already requested that about a year ago: Blacktocat.svg openstreetmap/operations/issues/351. --Nw520 (talk) 16:02, 14 January 2021 (UTC)
Request by topic author Blacktocat.svg openstreetmap/operations/issues/497 --Nw520 (talk) 16:03, 14 January 2021 (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:

Or this list 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)

Better description for tag statuses

I rewrote significantly (and exact copy at )

My intention was to have status values description matching actual use of statuses. Review and feedback is welcomed! Mateusz Konieczny (talk) 14:58, 10 January 2021 (UTC)

Renaming "Abandoned" to "Archived" in proposal template

See for discussion about this. Please comment only there to avoid fragmenting discussion, this is intended only as notification Mateusz Konieczny (talk) 09:45, 12 January 2021 (UTC)

Bot policy

Is there any clear consensus or documented rules about running bots on this wiki? Especially about bots active only for some language? In my case potential bot would edit only on pl: pages Mateusz Konieczny (talk) 08:31, 13 January 2021 (UTC)

Creating a page describing key or value

I created initial version of Creating a page describing key or value - review or expansion would be highly welcomed. Mateusz Konieczny (talk) 21:41, 15 January 2021 (UTC)