Talk:Wiki

This is the Wiki discussion area.

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

• If you have ideas for technical improvements to the way the wiki works, e.g. extensions we should install, you might add them here. For adding extensions, once discussed and consensus is present, a wiki admin should be requested to add the suggestion as an issue to Add Structured Discussions (Flow) Wiki Extension ^GitHub.

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

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

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

---

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

Stuck: The actual request was solved but there is no solution for https://github.com/openstreetmap/operations/issues/307 yet. --Tigerfell  (Let's talk) 12:01, 3 April 2022 (UTC)

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

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

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

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

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

What formatting and templates (if any) do multilingual WMF wikis such as Wikimedia Commons, meta.wikimedia.org and Mediawiki.org 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  (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  (Let's talk) 10:57, 25 May 2019 (UTC)

@Tigerfell Definitely your solution is more professional. Font of the page and line height are important but not as important as page direction. With your solution if we'll have visual editor, I think we would be comfortable with it. iriman (talk) 11:24, 25 May 2019 (UTC)

@Iriman: The feature was added in openstreetmap/chef/pull/239 ^GitHub. 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  (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  (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  (Let's talk) 17:23, 6 June 2019 (UTC)

It could be useful for language-specific formatting, for example font face (since it's a common need between all languages). This is a possibility only. Users of a language may need it, or not if default configuratuon satisfies them. For Fa, Ar, He, etc. currently we have font settings on our templates {{fa}}, {{ar}}, {{he}}, etc.iriman (talk) 10:59, 8 June 2019 (UTC)

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

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

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

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. https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dshelter&diff=next&oldid=1944254 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 https://www.wikidata.org/wiki/Q5007 )
• 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  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  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 button next to each row in the infobox, type the new value inline, and save without ever leaving the page. But there will always be a place for human-written, human-readable documentation regardless of data items. The body text is a great place to explain the real-world phenomenon expressed by the tag, how to find such things on foot or in imagery, common mistakes to avoid and how to fix them, external resources for learning more about the topic, and so on. For example, very little of the body text in Tag:emergency=siren or Tag:service=driveway overlaps with the infoboxes.

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

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

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

@Jeisenbe: I take it that you enabled the "Email me when a page or a file on my watchlist is changed" and "Add pages and files I edit to my watchlist" preferences? If you're receiving e-mail about every granular change to a data item, I can definitely understand that frustration. Have you considered disabling watchlist e-mails in favor of Special:Watchlist, which can group repeated changes to the same page or data item (as long as you keep "Use non-JavaScript interface" disabled)? I'm currently watching about 500 data items, but the automatic grouping keeps the noise down, and I'm trying to get the translation filter back up and running. If you prefer e-mail or a feed reader, perhaps you could configure your client to filter out notifications about data items. – Minh Nguyễn ^💬 06:46, 17 January 2020 (UTC)

"Have you considered disabling watchlist e-mails in favor of Special:Watchlist, which can group repeated changes to the same page or data item (as long as you keep "Use non-JavaScript interface" disabled)?" - I am using solely Special:Watchlist and it is also not capable of handling data items (unable to exclude translation edits in languages that are unfamiliar to me and show other edits). I am unable to keep them on watchlist as label-translation edits to them lead to an unreasonable spam. I never used email notifications Mateusz Konieczny (talk) 10:22, 17 January 2020 (UTC)

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

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

Same remarks apply to wikicode and templates. It is retricted to a small community mastering the edition of wikicode to change anything. Let's call it the OSM community. Fanfouer (talk) 16:05, 17 January 2020 (UTC)

I agree with Fanfouer here. I think much of this discussion is based on an unmerited bias towards wikicode. Lets face the facts:

1. wikicode as technology is +20 years old and besides adding Lua not much has changed
2. Wikicode might look pretty but it is notoriously hard to parse and a bad choice if that is your top priority
3. Wikibase is a fairly new technology with much improved data consistency and interoperability.
4. wikibase items can be improved from e.g. inside josm if we would like that
5. improvements to the documentation in items reach everyone, improvements in the wiki might only reach a minority understanding that language

I have the impression that with well documented items with qualifiers - I'm not so sure we need the body text anymore to explain use of tags. People in doubt can ask on a mailing list or on the talk page of an item. This might cause a steeped learning curve, or might not because the presets in both josm and ID are very nice and helpful and ease my memory so that I font have to remember a lot of tags. With data items we can have a mouse over popup that defines any tag the user sees on the screen. This is wonderful!--PangoSE (talk) 21:19, 17 January 2020 (UTC)

1. "not much has changed" - I consider it as a strong benefit. It means that there is much larger pool of people familiar with it. Old technologies are often worse than new technologies, but "X is an old technology, without breaking changes for a long time, familiar to many" is a strength, not a weakness
2. easy to edit, hard to parse - again, I consider this tradeoff as a strength. OSM Wiki is already hard to edit. Making it even harder, just to make parsing of data easier seems a bad change. Especially as data in the infobox templates is parseable and is already used, for example in taginfo!
3. I agree that keeping data in one place rather than in several is an improvement. But I am not convinced that it is so significant to make data items net positive.
4. Why we would want to allow editing summary of the article (template parameters/data items) without looking at the article? It will just encourage mismatch between article text and article summary
5. Can you give an example of some data item that without translation gives useful info? More than image + usage on way/node/area/relation + in use/de facto/deprecated/approved status already displayed by an infobox? I would expect that it is not enough to understand or use the tag.

I am pretty sure that qualifiers are not enough to replace entire article text, though it could be interesting to see this in action. Can you give examples of some complicated tag documentation article and its full replacement in the data item? (BTW, thanks for presenting your arguments!)Mateusz Konieczny (talk) 10:06, 18 January 2020 (UTC)

@Jeisenbe: -- RE: "Re: "...[it] keeps our tagging system from fragmenting between language communities. If hypothetically we were to abandon data items, we would still need a solution" - this is assuming that allowing tags to be used differently in other countries and language communities is a problem that must be stamped out, rather than a normal result of a global project which is adapted to local conditions in many different countries and language areas.
You are equating regions and languages. The language of the wiki should not be the deciding factor of what should be used where. I could be a Russian-speaking person living in Brooklyn/New York (huge community there, with older generation not speaking any English), or Russia (many different locales), or any other place. Portuguese is spoken in Portugal and Brazil - very different mapping communities. Regions on the other hand could have different rules. But those differences must be documented, hopefully in every language, to make sure everyone understands them including all the data consumers. So far I only know of one case like this -- Key:noexit is allowed on ways, but DE:Key:noexit prohibits it. Most other cases are the result of stale documentation - thus a huge documentation problem. Please see storing geographical differences and the following section about locales. --Yurik (talk) 05:04, 19 January 2020 (UTC)

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

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

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

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

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

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

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

"wiki is growing beyond what it was before" the difference is that with wiki pages I am intentionally not watchlisting for example German translation page. Data items are forcing me to watchlist all translations. That is why I am using Special:Watchlist, not Special:RecentChanges, Maybe data items have overall better UI and people prefer structured interface. Even at cost of horribly long loading time and slower editing speed. But is there any evidence that data items are overall more accessible or used more? Mateusz Konieczny (talk) 14:54, 21 January 2020 (UTC)

"So far, all I can surmise is that there's a lot more clicking, and that you need to keep other tabs open for context while you edit the data item." - horrible load time, each change must be saved separately, changes now require editing both description and a completely separate page Mateusz Konieczny (talk) 14:54, 21 January 2020 (UTC)

"the mailing list would've been a less confusing place to quote and reply" - I am not going to defend talk page interfaces in mediawiki, this is a clearly horrible hack that really deserves to be replaced. Though for OSM Wiki specific discussing it on Wiki seems a much better idea that using a separate forum like mailing list. Mateusz Konieczny (talk) 14:54, 21 January 2020 (UTC)

Data items - displaying P16 in Wiki lists

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

What you mean by nativekey and P16? (in my case "solution" is to not add data items to watchlist and treat them as separate project, unrelated to real OSM Wiki - though it would not help if someone wants to have data items on a watchlist) Mateusz Konieczny (talk) 16:40, 5 June 2020 (UTC)

You could move the labels of the items concerned to be aliases instead. @Yurik: Any other ideas? --Andrew (talk) 16:54, 5 June 2020 (UTC)

OK I could ignore data items and exclude the namespace :item from watchlist. But if we gonna ignore them, who cares (maintains) about them? - Don't get me wrong. I'm not keen on it. - I think a further separation of the data items from the Wiki must be avoided. Otherwise there will be 2 competing wikis for OpenStreetMap and it is not clear anymore which one will apply. So improving integration or wiping away data items. --Chris (Chris2map (talk) 18:21, 5 June 2020 (UTC))

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

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

In my opinion, given that there is no consensus to start blanking infoboxes doing this is not OK. At least on English language pages, not sure about translations. Mateusz Konieczny (talk) 08:02, 24 May 2021 (UTC)

This is mainly about translations and giving access to the same level of information to non-english mappers. If you only consider English then sure Data Items make a bit less sense, but please think about non-english speaking viewers. --Gileri (talk) 08:22, 24 May 2021 (UTC)

Also, please see Talk:Tag:highway=living_street#Blanking_infobox, Talk:Tag:highway=living_street#How_can_a_tag_imply_a_key.3F and Talk:Tag:highway=living_street#Conflict_about_.22info_boxes.22 for arguments already made about this issue. --Gileri (talk) 08:09, 24 May 2021 (UTC)

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

Thank you for you detailed input Chris2map !

I agree that the points you raise makes moderation/review harder. Do you think that having a readable watchlist/log/comments (metadata) are more important than having up-to-date content ? Also a big advantage of Data Items is that one can see edits on the one Data Item "page" instead of in each of 10+ languages, which they most probably can't understand the language for most of them. So those advantages may offset the problems you pointed out. --Gileri (talk) 20:20, 29 May 2021 (UTC)

The maintaining abilities aren't more important than the content. Nevertheless those are important to handle with the content and keep it right and up-to-date. But the underlying issue is how to switch to data items as base for the content of the infobox. Up to now the valid content is the one on wiki page and data item is only determined to be an extension with (automatically) copied data from wiki page. There has to be defined and described what changes are going to be made and how to manage the content data in future. Then it will affect all pages and there must be checked and decided for each page and item, if item data matches the actual page content, before switching infobox. Otherwise content showed on mismatching wiki pages would change at one swoop, even without a note in page history. So maybe it must begin step by step and could be started with the "description", the more so as "description" in data items is already being used by iD editor. I agree that editing the parameters in different languages is more forward at items than at wiki pages. --Chris2map (talk) 22:22, 29 May 2021 (UTC)

Okay, so if I understand you correctly you oppose a global change to infobox in one swoop. What I did, and what the conflict is about, is changing one or two infoboxes attributes to use Data Items, after manual verification that the content is up-to-date.
Also, you indicate that moderation issues makes it hard to follow Data Item changes. But currently one has to follow both Data Items and each and every language version of the tag page if they want to make sure there are no errors. After using Data Items, that makes a lot less content to follow, so that is a net gain, even with the current issues. --Gileri (talk) 09:12, 30 May 2021 (UTC)

Hi, I don't refer to the initiating conflict. My request is what global solutions are there and how to get there (to dissolve duplicity of content data). I'm still open with my position. Actually I would be glad if we could move "description", "use on..." and "status" to data items, and could maintain them in one place. But I think if we (two) do this simply in one swoop by changing templates of infoboxes, there would occure at least 3 problems popping up: 1st) An outcry of part of the community. 2nd) How to ensure that the more up-to-date data has been adopted (if there are discrepancies between wiki and item, as I mentioned above). 3rd) How should the data or parameters be deleted from the wiki pages? So I'm definitely in favor of improving the current situation. Hence my consideration of whether a small step is somehow practical. Do you have an idea for a bigger swoop? --Chris2map (talk) 11:25, 30 May 2021 (UTC)

I don't have ideas to change every infobox at once. Even if I did, based on the resistance on some vocal users for the tiny change I did, I think such an endeavor is bound to fail, sadly. But I would be glad someone with more time and energy on the issue found a way to both solve the technical issues, and convincing that structured data in the wiki for OSM, a structured data project, is a good thing. --Gileri (talk) 11:37, 30 May 2021 (UTC)

Couldn't an update to the template with a check for correct data duplication with warning or error messaging be a solution ? The new infobox would display the wikidata item if it would fits the infobox content from the wiki page. If there is inconsistencies, or wikidata is non existent both values could be displayed in the infobox and the infobox template could generate a "clean-up" or "warning" ambox or a category as you like. This would allow for a gradual transition, a new global changed infobox template but for all at once, as data inconsistencies are clearly displayed and the amboxes or category can be used to trace data duplication errors. Even after a transitional period, I expect that many wiki editors will not feel familiar enough with wikidata to edit it whenever a tagging addition or change is eminent. So the "transitional" template might as well work as a permanent solution and provide more efficient tracking tools for data duplication. --Bert Araali (talk) 12:32, 30 May 2021 (UTC)

"This would allow for a gradual transition" - what should be done only if there is a clear support for such transition. ""clean-up" or "warning" ambox or a category as you like" - such categories exist already, see Category:Mismatched wikidata, Category:Mismatched onArea etc. Mateusz Konieczny (talk) 11:39, 31 May 2021 (UTC)

What I am missing in this discussion so far are ideas - by those opposed to the use of data items and of course others as well - how to make sure that mappers who do not speak English can participate in OSM. In other words, how do we keep documentation consistent about language versions. And if the idea is "Someone monitors changes and adapts the existing translations" I would like to know who that "Someone" is and if "Someone" agrees to take the job. --Lyx (talk) 15:36, 31 May 2021 (UTC)

Actually, for keeping translation in synch data items are worse than OSM Wiki pages. There is no effective way to notice that something is changed (as watchlisting data items fills watchlist with translation updates in all languages, including ones where you cannot review changes). That is why I am against blanking infoboxes, it would Watchlisting wiki page in your language and in English is right now the best solution. And for parameters in infoboxes like onArea - I would be happy to generate list of mismatches if anyone would be interested and keep it up to date. If anyone actually interested in fixing such mismatches - which language is interesting for you? Mateusz Konieczny (talk) 16:19, 31 May 2021 (UTC)

I think you missed the "do NOT speak English" in my comment above. I don't worry so much about Wiki translators or editors but about readers who just "consume" wiki pages to find out about tags they want to use. With data items they could get at least rudimentary information consistently auto-translated instead of (in worst case) nothing that they can read. --Lyx (talk) 18:55, 26 March 2022 (UTC)

Detecting differences between infoboxes in English and translated pages

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

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

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

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

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

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

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

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

1 is important to me, 2 is nice to have but not critical, 3 is not a good idea at all as it disallows making a new translation page with the most important info and skipping less important parts. Mateusz Konieczny (talk) 20:48, 26 March 2022 (UTC)

CAPTCHA

Stale: No progress on the technical side. --Tigerfell  (Let's talk) 12:03, 3 April 2022 (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 https://github.com/openstreetmap/operations/issues/19 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  (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 https://meta.wikimedia.org/wiki/Nofollow ) - 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. openstreetmap/operations/issues/383 ^GitHub --Tigerfell  (Let's talk) 10:57, 26 March 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 https://github.com/taginfo/taginfo/issues/201 and https://github.com/taginfo/taginfo/issues/223 --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 , 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)

Hi, I fixed all problems on the page Map_features : the solution with dash doesn't work properly, the good solution for taglists needs 2 steps. 1. underscores don't work (as it was said above) : you have to put a space instead and only a space. More precisely, if you have an underscore in the name of the file for the osmcarto-rendering parameter in the ValueDescription of the tag, page in English, you have to replace it by a space. Example : for the tag tree_row, the name of the rendering file is File:Rendering-natural_tree_row-mapnik.png. In the osmcarto-rendering, you have to write : osmcarto-rendering=File:Rendering-natural tree row-mapnik.png. 2. You have to wait one day to see the result : taglists work with the taginfo API. Taginfo is updated once a day so you have to wait the next update to see the result in your taglists. Best regards. Fred73000 (talk) 18:38, 20 January 2022 (UTC)

Followup on CAPTCHA

Stale: OWG issue is stale, we cannot do anything. --Tigerfell  (Let's talk) 12:05, 3 April 2022 (UTC)

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 https://github.com/openstreetmap/chef/issues/298. --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  (Let's talk) 11:26, 6 June 2020 (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: https://taginfo.openstreetmap.org/tags/highway=footway#wiki --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 https://wiki.openstreetmap.org/wiki/Category:Data_item_issues Mateusz Konieczny (talk) 08:18, 10 October 2020 (UTC)

For example https://wiki.openstreetmap.org/wiki/Category:Mismatched_onNode (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 https://github.com/matkoniecz/osm_wiki_tag_api 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)

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)

@Minh Nguyen: - thanks for developing this, how it would be deployed? As filler on text of any page not created after entering it? Filled after deliberately pushing some button? Mateusz Konieczny (talk) 07:30, 21 January 2021 (UTC)

The "try it out" link above previews what a redesigned MediaWiki:Noarticletext would look like. This is the message that shows up when you go to a page like https://wiki.openstreetmap.org/wiki/Tag:yes=no. When you click "Create this page", you're taken to a prefilled edit page, which you can fill out and preview before publishing. You can of course continue to edit the page afterwards. Users who know what they're doing can click the "Create" tab at the top of the page to get a blank edit page, or they can simply delete all the boilerplate text and start from scratch. If this is confusing, perhaps the Noarticletext message could offer both options. – Minh Nguyễn ^💬 18:33, 21 January 2021 (UTC)

I am unsure about gallery by default. Problem that repeats is that page supposed to describing tag has massive gallery that ads nothing to an article Mateusz Konieczny (talk) 07:30, 21 January 2021 (UTC)

The sections included by default are by no means meant to be required, and sections that aren't needed should be deleted. Perhaps the comments should make that clearer. I was under the impression that galleries are common enough and figured that the <gallery> syntax is fairly obscure. – Minh Nguyễn ^💬 18:33, 21 January 2021 (UTC)

What is the plan to make clear that user should save page so that "{{safesubst:#invoke:DescriptionFromDataItem/sandbox|preload|key={{safesubst:#invoke:OsmPageTitleParser|" will generate something? Mateusz Konieczny (talk) 07:30, 21 January 2021 (UTC)

Good question. We can add a message above the edit box (in wikitext mode) and in a flyout panel (in the visual editor) that explains what that gobbledygook does. It would take the place of the existing MediaWiki:Newarticletext message. I'd love to make the infobox code look more like an infobox in the visual editor, but I think safesubst: interferes with that. – Minh Nguyễn ^💬 18:33, 21 January 2021 (UTC)

"Where to find them" section seems unusual, not sure whatever have seen it usefully used anywhere and is quite rare anyway. Why it is needed if there is both description of feature and how it is mapped? Mateusz Konieczny (talk) 07:30, 21 January 2021 (UTC)

Sometimes mappers see something in imagery and want to know how to map it, but other times they're browsing the wiki, see something interesting, and wonder if they can map any instances of it in their own area of interest. The definition doesn't always make it obvious where to find the feature, because the location may differ between regions, cultures, or levels of urbanization. Separately, many organized mapping teams have developed their own training materials to supplement the wiki; as far as I can tell, this is a common element of those training materials. In general, I would like the wiki to address the aspects that are currently exclusively covered by those training materials, so that the wiki can be more authoritative and there's less opportunity for conflict between the community and mapping teams.

You're right that this section is relatively uncommon (and sometimes titled differently), but I do think the content that has been placed within this section so far has been pretty useful. I only included "Where to find them" on the tag description boilerplate, because keys on their own don't represent features; some key description pages have an analogous section called "Rationale" or "Use cases". I'm hoping this boilerplate sparks a discussion about the "standard" sections of tag description pages from a reader perspective, but perhaps I'm trying to do too many things at once. :-)

 – Minh Nguyễn ^💬 18:33, 21 January 2021 (UTC)

Usage of icons on boundaries

The use of the icons and are used inconsistently across the wiki when it comes to boundaries (specifically, relations tagged with type=boundary). It is clear that 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 , , or ?

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

1. Does apply to relations of type=boundary?

Yes	No
Template:Map_Features:boundary	boundary=administrative Template:ValueDescription Template:KeyDescription Area Types_of_relation

2. Does apply to relations of type=boundary?

Yes	No
boundary=administrative Template:ValueDescription Template:KeyDescription Area	Template:Map_Features:boundary Types_of_relation

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

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

DynamicPageList extension

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

• 22 December 2020: Proposed features/golf cart path
• 21 December 2020: Proposed features/addr:interval
• 28 November 2020: Proposed features/wait

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

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

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

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

+1 if this extension is not introducing some noticeable complexity. Is there a real risk of increased instability and poor performance if we keep enabling bunch of extensions? Here benefits seems minimal Mateusz Konieczny (talk) 10:00, 11 January 2021 (UTC)

I can't speak for the cumulative effect of many extensions being enabled, but one way of looking at it is that we have far fewer extensions installed than a typical Wikimedia wiki, while the community seems to expect a similar level of service. DynamicPageList is fortunately a relatively simple extension, befitting its relatively minimal benefits, but I think your concern is worth keeping an eye on. – Minh Nguyễn ^💬 06:55, 20 January 2021 (UTC)

 Support --Lectrician1 (talk) 15:01, 8 February 2021 (UTC)

I  Support it. maro21 18:13, 5 May 2021 (UTC)

 Support --Tordanik 20:52, 7 May 2021 (UTC)

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

Add TemplateStyles Extension

openstreetmap/operations/issues/509 ^GitHub

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

https://www.mediawiki.org/wiki/Extension:TemplateStyles

Any objections?

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

Custom CSS is possible now, it just needs to be installed by an admin. I had to do this for my taginfo box replacement project. No need for a separate extension AFAIK. @Minh Nguyen: --ZeLonewolf (talk) 04:05, 6 February 2021 (UTC)

Yes, Minh and I discussed this. However I run into the issue of not being able to test the css and how it looks on a page before I commit to the actual page. I want to use my user pages to test both the Main Page Wikitext and CSS combination. Not being able to test means going through a admin is practically unreasonable. It's also nice to have publicly-available css stylesheets for easy reference and changes. All Wikimedia projects have this extension and it's been very handy to work with in the past before. --Lectrician1 (talk) 05:03, 6 February 2021 (UTC)

That doesn't make any sense, I had no problem testing my CSS without any special extension. --ZeLonewolf (talk) 05:19, 6 February 2021 (UTC)

Following up from our private conversation, hopefully your browser's built-in developer tools provide the facilities you need to prototype style rules for the main page. TemplateStyles is a nice extension to have, but it is already technically possible to implement something similar without TemplateStyles by writing a user stylesheet that an administrator can turn into a gadget or copy into MediaWiki:Common.css. Gadgets and sitewide stylesheets affect every page for every user, so it's important to scope style rules, for example by prefacing each ruleset with .page-Main_Page .bodyContent. Even then, there is extra overhead loading any page on the wiki, so consider inline style attributes if possible. TemplateStyles is nice to have because you can express more than style attributes but without adding overhead to unrelated pages. – Minh Nguyễn ^💬 09:35, 6 February 2021 (UTC)

How can other users see the programmed css for a page after an admin has added it. What if they wanted to redo the main page after me in the future and reference the old css?
In my opinion, using browser tools is going to be much more of hassle for me than just having the easily-installable TemplateStyles.
I also just thought of another conflict I might run into. If I'm using templates on the main page that rely on their own css, will the css I program for the template and main page show up? Templates render based on their source page and if the source page has no css, I'm not sure this will work. The template won't be able to pick up any css references either since it's only coded presence on the main page will be {{Frame}}.
--Lectrician1 (talk) 13:53, 6 February 2021 (UTC)

Okay I tested my "possible problem" and turns out css does work for templates that are transcluded on another page.
However, can we please just add the extension out of convenience?
Evey time I want to change the wikitext, I have to copy and then reinsert the css into into my browser developer panel. There is a lot of Wikitext I'm going to have to change for the main page. This is going to be a big hassle.
Also, as I noted before, it's nice to have the css stored in a file everyone can easily reference, rather than wherever an admin has to store it ingrained in the page. --Lectrician1 (talk) 23:26, 12 February 2021 (UTC)

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

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

Give auto-confirmed after 2 days, not 4?

I just run in case of a mapper (User:Cartographer10) unable to upload files, unable to move their own proposal because their wiki account has no autoconfirmed status. Maybe give this right quicker?

It appears to be defined at https://github.com/openstreetmap/chef/blob/dfc631109a486788a18b57da696c06339368993e/cookbooks/mediawiki/templates/default/LocalSettings.php.erb#L248-L250

I propose to give it after 2 days, not 4.

Mateusz Konieczny (talk) 09:27, 6 February 2021 (UTC)

•  Support I see no vandalism on the Wiki anyways so unless this change ends up causing it, then we should be okay. --Lectrician1 (talk) 13:41, 6 February 2021 (UTC)

•  Support Never really any spam onwiki, changing it wouldn't cause any harm. Berrely ^(T•C) 14:56, 6 February 2021 (UTC)

• There is spam occasionally, but it gets deleted quickly. --Jeisenbe (talk) 19:52, 6 February 2021 (UTC)

• Oppose I am not necessarily against the proposal, but the timing is very unfortunate. We just changed the configuration with your support, Mateusz Konieczny. As of now, there is a solution and I would prefer if we try that out first instead of approaching the sysadmins once a week and discussing the same topic over and over again.
  BTW, the linked user account is currently autoconfirmed and has not uploaded any files. --Tigerfell  (Let's talk) 19:44, 14 February 2021 (UTC)
  • Files were uploaded by someone else, based on their request. And note "unable to move their own proposal" part - is it also solved by this recent change? Mateusz Konieczny (talk) 07:56, 17 February 2021 (UTC)

Yes, confirmed users can move pages. There is a list of permissions at Special:UserGroupRights. --Tigerfell  (Let's talk) 19:13, 17 February 2021 (UTC)

I have to admit that there is a flaw in the configuration which I just noticed after writing the previous comment. As you can see from Special:UserGroupRights#confirmed, confirmed users have to solve the CAPTCHAs. Additionally, they can not fix transcoding errors. The major objective of the previous configuration change is still fulfilled, but I guess my argument is void if you mind the CAPTCHAs and all of the problems they cause. --Tigerfell  (Let's talk) 14:21, 20 February 2021 (UTC)

As a side effect, openstreetmap/chef/pull/400 ^GitHub aims to fix the shortcomings of the current configuration, but it will not change the autoconfirmation period, because the pull request targets namespaces, and I was asked not to combine unrelated changes into one pull request. --Tigerfell  (Let's talk) 14:59, 20 March 2021 (UTC)

Authentication from osm.org

openstreetmap/operations/issues/507 ^GitHub

OAuth login to Wiki is a Top Ten Task

PluggableAuth looks like a suitable extension for this.

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

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

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

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

Enabling OAuth2 authentication between osm.org and the wiki should be the #1 priority for new features to the Wiki. The lack of this seamless authentication is often cited as a barrier to entry for participation in tagging discussions. Issues that need to be addressed:

• What is the process for linking existing wiki usernames to osm.org usernames in a way that's straightforward for users and not a burden on admins?
• Will the process be seamless for new users?
• Do we have an issue in the case of name collisions? (in which an osm.org user and a wiki user of the same name are actually two different people)?

--ZeLonewolf (talk) 22:18, 8 February 2021 (UTC)

• It seems that as long as an account on the Wiki and OSM have the same username and/or (not sure) email, then they can login.
• Yes, it is seamless.
• I think the emails being the same is the deciding factor.

--Lectrician1 (talk) 22:26, 8 February 2021 (UTC)

It would be great to eliminate this barrier for participation on the wiki, seems very promising! I've got some questions as well:

• What does it mean that the process is seamless for new users? Can they just log in using their existing account without having to "create a wiki account" first?

Yes. If a Wiki account does not exist with the username and email that is returned by the osm.org client, then a new account for the Wiki will be created and the user can continue to use osm.org to login. --Lectrician1 (talk) 17:24, 14 February 2021 (UTC)

• I understand that the plan for dealing with differences between the two sets of accounts is that users resolve these themselves (by changing their user name and/or email address so that they match, or creating an OSM account for wiki accounts that don't have an equivalent yet)? For that to be possible, there will be a co-existence of linked accounts and un-linked accounts at least for a transition period, right?

Correct. It is up to the users to decide when and whether they want to "link" them. They can do so at any time because the login process will remain the same always. --Lectrician1 (talk) 17:24, 14 February 2021 (UTC)

Thanks for attacking this long-standing problem! --Tordanik 14:04, 14 February 2021 (UTC)

PluggableAuth may not be sufficient to address the issue, at it is only a framework to create authentication and authorization extensions on top of it. Also, OAuth2 authentication isn't available yet on the Rails port (osm.org website), which means we cannot use plugins like OpenID Connect. Then, having an explicit link between the Wiki and osm.org (vs. an implicit one which relies on the same username across both sites) is the preferred option. Matching via username and email also wouldn't work, because we deliberately don't expose users' email addresses via any API call for privacy reasons. There's quite a bit of work involved here which goes much beyond installing a Wiki plugin. mmd (talk) 11:40, 21 February 2021 (UTC)

@Mmd: What would you suggest be the steps we should take to making this happen then? How exactly could we establish an explicit link? --Lectrician1 (talk) 07:22, 22 February 2021 (UTC)

Well, finding that out would be exactly one of the tasks of the Github issue. We probably need some Mediawiki expert and/or more research to work out possible solutions. Think of the whole topic more in terms of a project, rather than some few hour configuration task. Mmd (talk) 09:36, 22 February 2021 (UTC)

Hm ... the goal discussed in some previous conversations, and when writing that Top Ten Tasks entry, was to eventually get rid of the distinction between OSM wiki account and OSM account as far as practically possible – i.e. users would have the same name, and there would be no need (and no ability) to "create a wiki account". How would the process of establishing an explicit link look for an OSM user editing the wiki for the first time? --Tordanik 19:29, 26 February 2021 (UTC)

@Tordanik: They could sign in with osm.org and their account would be created based on the information returned by the osm.org OAuth client. This would work exactly the same as when you login/signup with Google on a site and you are able to immedeatly use it. --Lectrician1 (talk) 02:23, 27 February 2021 (UTC)

It seems that further activity would be at https://github.com/openstreetmap/operations/issues/507 - and that is solved as far as we can here, right? Mateusz Konieczny (talk) 10:13, 19 March 2021 (UTC)

Maybe create Authentication from osm.org describing the situation? Mateusz Konieczny (talk) 11:08, 6 March 2022 (UTC)

There is Develop/Single sign on. --Tigerfell  (Let's talk) 12:08, 3 April 2022 (UTC)

Add Page Forms Extension

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

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

For example, a Page Form could allow:

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

Here are examples of sites that use Page Forms.

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

"Proposal can change stages from draft to proposed to voting to post-vote, all with the configuration of the form. This requires no editing of the proposal itself." - how it would be detected?

"easily-inputable and displayed in a standard fashion" - how it deals with fact that proposal may propose one new key or new value or values or deprecate existing tag or change voting rules or introduce new key and deprecate specific value (or values) and so on? Mateusz Konieczny (talk) 07:54, 17 February 2021 (UTC)

• @Lectrician1: - have you tested how this extension interacts with all subsets of extensions that you also proposed? And with current OSM Wiki install? Mateusz Konieczny (talk) 10:44, 23 February 2021 (UTC)
  • @Mateusz Konieczny: I'm going to setup my own install of MediaWiki and test before I suggest we move forward with actually implementing it.
    Also for, "How would it be detected". What I mean is that with Page Forms none of the raw text on the proposal has to be edited. Everything is configured through the form. Selecting an option for a proposal stage in the form should be able to automatically add the voting section to the proposal, etc.
    Form elements are also replicatable so you can setup a field to repeat itself with multiple options. For example, you can add as many tags that you want to propose addding or depreciating etc. IDK if this makes sense :P
    --Lectrician1 (talk) 16:22, 23 February 2021 (UTC)

Bug displaying images on Discussion pages in Mobile View ?

When you switch to Mobile view, images are converted to

<img>

on normal "Page" wiki pages.
However, when you include images on a "Discussion" page, they are converted to

<span ...> </span>

. This makes them appear as whitespace.

This does not happen in "Desktop" view.

Example: Insert the following template

{{User|Bert Araali|osm=Bert Araali|m=1|noedits=1}}

the transcluded image in the template on a normal "Page" wiki page (switch to Mobile view) will be converted in HTML as:

<img alt="User icon 2.svg" src="https://upload.wikimedia.org/wikipedia/commons/thumb/1/12/User_icon_2.svg/18px-User_icon_2.svg.png" decoding="async" srcset="https://upload.wikimedia.org/wikipedia/commons/thumb/1/12/User_icon_2.svg/27px-User_icon_2.svg.png 1.5x, https://upload.wikimedia.org/wikipedia/commons/thumb/1/12/User_icon_2.svg/36px-User_icon_2.svg.png 2x" width="18" height="18">

On a "Discussion" page (in Mobile view) will be converted to:

<span class="lazy-image-placeholder" style="width: 18px;height: 18px;" data-src="https://upload.wikimedia.org/wikipedia/commons/thumb/1/12/User_icon_2.svg/18px-User_icon_2.svg.png" data-alt="User icon 2.svg" data-width="18" data-height="18" data-srcset="https://upload.wikimedia.org/wikipedia/commons/thumb/1/12/User_icon_2.svg/27px-User_icon_2.svg.png 1.5x, https://upload.wikimedia.org/wikipedia/commons/thumb/1/12/User_icon_2.svg/36px-User_icon_2.svg.png 2x"> </span>

.

--Bert Araali (talk) 21:41, 24 March 2021 (UTC)

@Bert Araali: I think it works for now. Just tested it. --Chris2map (talk) 18:35, 8 July 2022 (UTC)

Template:Languages/div Mediawiki bug

Unresolved

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

The same for me:

[ecf673d83453ac48a248f2fa] 2021-05-03 23:11:13: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

--Vazhnov Alexey (talk) 23:15, 3 May 2021 (UTC)

Reported openstreetmap/operations/issues/533 ^GitHub --Tigerfell  (Let's talk) 17:14, 14 May 2021 (UTC)

The reply suggests that there is an issue with that wiki page. Since I do not even know what the template does I will not change it. --Tigerfell  (Let's talk) 10:59, 16 May 2021 (UTC)

As Template:Languages/div and Template:LanguageLink are no longer used since Minh rewrote Template:Languages and the wiki has never had any pages in Marathi the only real concern is what the underlying problem is. Has this been reported on the Mediawiki bug tracker? --Andrew (talk) 15:44, 16 May 2021 (UTC)

I can only speculate that the lack of any Marathi pages on the wiki might have triggered the error. Since I removed this language, the database error no longer occurs. Mmd (talk) 17:00, 16 May 2021 (UTC)

Looks like there is something wrong with the Marathi language in {{Languagename}} template.

See for example

{{Languagename|de}} -> Deutsch

{{Languagename|abc}} -> abc

but {{Languagename|mr}} throws an error

This template uses magic word #language but {{#language:mr}} works well.

{{#language:ar}} -> العربية

{{#language:br}} -> brezhoneg

{{#language:mr}} -> मराठी

I'm still thinking how to solve it. maro21 16:57, 18 May 2021 (UTC)

The {{Languagename}} template was used enthusiastically by, and over-engineered by, a former wiki contributor for purposes such as enabling links to Wikipedias in languages without Mediawiki support. Many (not all) uses can be (and often have been) replaced with #language; {{Languages/div}} needed it for gcf: until the current language template made it redundant. --Andrew (talk) 19:48, 18 May 2021 (UTC)

We could revisit the remaining templates with languagename and convert as many as possible to #language. --Andrew (talk) 05:50, 20 May 2021 (UTC)

I didn't say that we should get rid of the template:). There was a problem only with Marathi language but this language isn't used on this Wiki at all. I think there is a bug with the database somewhere, the template is ok. maro21 19:28, 20 May 2021 (UTC)

Wiki:Babel templates was also affected through Template:Babel list of languages, fixed by replacing Languagename with #language. --Andrew (talk) 11:40, 20 May 2021 (UTC)

I think I’ve found the problem. {{#language:mr}} (Marathi, native name) works correctly. {{Languagename|mr}} expands to {{#language:mr|mr}} (Marathi, in Marathi), which doesn’t. {{#language:en|mr}} (English, in Marathi) also fails. There is no problem with {{#language:mr|en}} (Marathi, in English) so OsmAnd renders. Tagalog has the same problem ({{#language:tl|tl}} fails) and there may be others that we don’t refer to on this wiki. --Andrew (talk) 17:49, 23 May 2021 (UTC)

Good job! But where are these defined? Somewhere in the Mediawiki files? I've never seen source code of Mediawiki and I don't even know where to look for. I checked your examples on English Wikipedia and they work well. maro21 18:07, 23 May 2021 (UTC)

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/cldr/+/refs/heads/master/CldrNames/CldrNamesMr.php --Andrew (talk) 19:02, 23 May 2021 (UTC)

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

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

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

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

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

Category Tree extension missing

Stale: code ready to be merged + approved, but it was never merged --Tigerfell  (Let's talk) 12:10, 3 April 2022 (UTC)

Since MediaWiki 1.31, CategoryTree extension is packaged by default, we are running version 1.35, so why is it removed. It is a standard and very nice extension to view categories as dynamic intercative trees and could improve our wiki and navigation a lot. So this is a request to leave it included.

https://www.mediawiki.org/wiki/Extension:CategoryTree and https://www.mediawiki.org/wiki/Help:Categories#Managing%20the%20category%20hierarchy.

--Bert Araali (talk) 15:16, 18 May 2021 (UTC)

The extension's files are included in MediaWiki, but one would need to enable the extension. This is not done automatically. --Tigerfell  (Let's talk) 20:52, 19 May 2021 (UTCi

So is one of the admin's willing to enable it ? Any objections or issues against enabling it ? Bert Araali (talk) 22:12, 19 May 2021 (UTC)

@Bert Araali: Administrators unfortunately don't have access to the configuration files that load extensions. You'll need to ask the sysadmin team to enable CategoryTree. – Minh Nguyễn ^💬 10:13, 19 September 2021 (UTC)

@Minh Nguyen: I think Bert Araali intended to ask if one of the wiki administrators supports the request.

I think the extension could be useful when cleaning up categories or just searching for articles via categories (like looking for a similar tool). I just did not yet managed to look at it in more detail. Someone else proposed to add Extension:DynamicPageList (Wikimedia). I wonder if the use cases of both extensions overlap and we should choose either of them. --Tigerfell  (Let's talk) 21:02, 28 October 2021 (UTC)

@Tigerfell: CategoryTree is different than DynamicPageList, which was proposed earlier this year. The former makes it easier to browse any existing category, while the latter powers special lists based on categories (or category intersections), for example "the latest pages in both A and B but not C". Such a list would be explicitly added to a page in wikitext, similar to how we integrate with OSMCal today. Of the two extensions, CategoryTree would be a no-brainer: it's convenient and, if anything, would reduce load on the servers because users wouldn't have to load full category pages in many cases. – Minh Nguyễn ^💬 22:45, 28 October 2021 (UTC)

I requested the extension to be added to this wiki in openstreetmap/chef/pull/463 ^GitHub. --Tigerfell  (Let's talk) 16:06, 7 November 2021 (UTC)

Legal requirements to images or media files

> Main topic: Category:Media without a license

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

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

• There is one short and unclear note at Wiki_Help. And that page not even is linked at mainpage or main help page Get_help. (Another issue itself.)

• Even at the Special:Upload page there are several hints but there is no given help what licenses must or can used basically.

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

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

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

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

At Special:Upload you first see MediaWiki:Uploadtext, at least if you see this page in English, German, or Spanish. It mostly focuses on the question whether the uploaded files are relevant to this wiki not so much on licensing. The upload page also features a dropdown menu for selecting the correct license. This is taken from the configuration page MediaWiki:Licenses. Licenses in this list are definitely acceptable. Media license templates lists all licenses I know. I guess the problem with GFDL is that you are not allowed to trace from such files for OSM. I do not know why it should be a problem to upload such files.

Some sort of guideline could be useful.

I currently do not fix the licensing issue because there are still the options to select "None selected" and "I don't know exactly" which leaves it up to others to fix the licensing. This is often more difficult because you have to find out if the uploader took the picture by themselves etc. Just looking at the last ten uploads (until 19:15, 2 November 2021 UTC) you find four without any licensing and one with a contradicting licensing combination. --Tigerfell  (Let's talk) 23:02, 2 November 2021 (UTC)

By the way, this topic also came up recently in relation to a claim of fair use, which is of questionable applicability to a website based in the United Kingdom or European Union. We should at least do something about Category:Labelled for deletion, but Category:Media without a license needs a lot of work to contact the uploaders for more information (giving them a fixed amount of time to respond before deletion, that sort of thing). – Minh Nguyễn ^💬 01:43, 3 November 2021 (UTC)

Deciding whether we can and should keep fair use images is one of things that needs to be done Mateusz Konieczny (talk) 09:55, 3 November 2021 (UTC)

Category:Labelled for deletion can be emptied only be people with admin rights and they do it, though quite slowly (but there is no real backlog here) Mateusz Konieczny (talk) 09:55, 3 November 2021 (UTC)

Category:Media without a license - what you think about splitting it into subcategories "uploader not notified" and "uploader notified", with second split based on notification date? This would make easier to ensure that all editors are notified and later to start deleting images where uploaders were notified and failed to respond for a long time. Right now processing this category is irritating as many images are stuck in limbo, without any action to be taken for now Mateusz Konieczny (talk)

That could work, though it's even more manual work. Wikipedia and Commons actually use a bot to handle these notifications. Smaller Wikipedias don't run bots for them, but most wikis have a template similar to {{Unknown}} that automatically adds the page to a category based on whether it's been tagged for more than a week (or some other time period). That kind of automation requires using the subst: keyword when inserting the template. – Minh Nguyễn ^💬 17:56, 3 November 2021 (UTC)

I actually have plans to automate this a bit - but I want to design process before sending thousands of notifications, also it would be nice to have it runnable without relying on bots (even if it would be more tedious). And yes, something subst: based would be included Mateusz Konieczny (talk) 11:50, 4 November 2021 (UTC)

Thanks for your replies! The ideas to straighten or establish a process to handle the license issue sound good. The template to categorize the contacted cases might automatically switch from "uploader notified" to "uploader notified without reaction" after 4 weeks since placing the template (if this works). - The other part, an explanation for normal users what are the requirements, should been made available as quick as possible. Last week I contacted a user who recently uploaded loads of images and he will/might subsequently add source (own pictures) and license information. He didn't complain, but understandably will not be delighted to edit dozens of file pages. - Is there anywhere a kind of document that can provide a basis for the explanation? --Chris2map (talk) 20:41, 4 November 2021 (UTC)

Talk:Wiki#PD-shape_to_series_of_images is related topic where help would be welcome and basically anyone can do this Mateusz Konieczny (talk) 15:31, 27 November 2021 (UTC)

I linked Wiki Help at Get Help Mateusz Konieczny (talk) 13:07, 8 December 2021 (UTC)

• Addition to MediaWiki:Uploadtext

Please have a look at MediaWiki_talk:Uploadtext#Addition_of_two_basic_statements. I'm proposing two basic statements for the file upload page. --Chris2map (talk) 16:38, 28 December 2021 (UTC)

TODO

MediaWiki:Uploadtext - Addition of basic statement

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

-- (copy of last 3 comments) --

I see your points. Let's try a conclusion:

I . Please do not upload any file without clarifying and indicating the source!

II . a) If you are the author of this file, you must make it available under a free license.

b) If you are not the author of the file, the file must be under a free license and you must provide the source.

c) In any other case you have to clarify the legal use and compatibility with OpenStreetMap Wiki. A file without source and license will be deleted later.

(The linked pages would still have to be created.) What do you think? Please check my wording. --Chris2map (talk) 12:41, 29 December 2021 (UTC)

Technically, https://wiki.openstreetmap.org/wiki/Talk:Wiki#Designing_policy_for_handling_files_without_clear_license seems to trend toward allowing at least some unfree images. But maybe it is not necessary to mention it in summary, just link to full version somewhere? But it would be nice to clarify upload text before we handle fair use and have some clear policy on that. Mateusz Konieczny (talk) 13:18, 29 December 2021 (UTC)

I suggest we continue the discussion in the linked thread on Talk:Wiki given the general impact with regards to file uploads. --Tigerfell  (Let's talk) 13:24, 30 December 2021 (UTC)

-- (end of copy) --

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

I thought it would be more useful to establish the licensing guideline first and then change MediaWiki:Uploadtext and all of its translations accordingly. Otherwise, we would need to change it multiple times. --Tigerfell  (Let's talk) 13:08, 31 December 2021 (UTC)

I definitely have to agree with you on the need of a comprehensive guideline and that file upload page should be changed as few as possible. However, the statement "I." of above is matching the common state and appropriate without further guidelining, IMHO. I would like to bring this forward. --Chris2map (talk) 08:57, 2 January 2022 (UTC)

Guidelining chart for media file licensing

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

Thank you for that! Maybe asking LWG for review could be useful? Mateusz Konieczny (talk) 08:03, 6 January 2022 (UTC)

Yes, at least we could ask. Per which way? legal-talk mailing list? - Should we go soon or first turn another round in wiki and try to get more feedback from team or contributors? This was my intention. --Chris2map (talk) 12:31, 6 January 2022 (UTC)

It would be nice to get more feedback before taking any further steps of survey and proposing. I don't want to rush ;) --Chris2map (talk) 15:02, 6 January 2022 (UTC)

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

Designing policy for handling files without clear license

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

We have many files that are blatant copyright violations.

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

There are following groups

1. Clear copyright violations - obvious copyright violation, also files where uploader admitted that files are copied from random website, Google Street View or source is stated. Or files copied from Wikimedia Commons that were deleted there.
   • Such files should be identified and marked with {{Delete}} template
2. Files openly licensed and marked as such with proper licensing template, with clear source
   • Not a problem
3. Files where licensing info is stated, but in text rather than using a proper licensing template
   • In such case licensing template should be applied
4. Files where licensing info is missing and author was never notified about problem
   • There is ongoing work to automate this, see https://wiki.openstreetmap.org/wiki/Talk:Wiki#Legal_requirements_to_images_or_media_files
5. Files that were clearly uploaded in good faith by OSM mappers, but without any licensing info and uploader is inactive
   1. What should be done with such files? Delete? Keep and mark specially?
      • Example where authorship is nearly certain: https://wiki.openstreetmap.org/wiki/File:20080615_LondonToBrightonBikeRide2008_157.jpg
      • Example where it is not entirely clear who is the author: https://wiki.openstreetmap.org/wiki/File:IndoorFireHose-non.jpg
6. Fair use - unfree images that re impossible to replace and important
   • Example: https://wiki.openstreetmap.org/wiki/File:Free.png (for crediting sponsor)
   • Also, most of https://wiki.openstreetmap.org/wiki/Category:Logos
     • Ones that are complex enough to qualify for copyright and in use beyond mere decoration
       • Very simple are {{PD-shape}}
       • Ones where use is not critical are not qualifying for fair use
   • File:2021 torokbalint ortofoto engedely.webp - permissions to use data may be copyrighted (or not), in both cases it should be fine to upload them here. See Category:Images of data use permissions, rejections or requests
   • And for example https://wiki.openstreetmap.org/wiki/File:OpenStreetMap_data_used_by_Google_Maps.png documenting something relevant where fully free image is inherently impossible
   • Probably also https://wiki.openstreetmap.org/wiki/File:124787243-5992ce80-df16-11eb-9809-ab731f25733d.png requires fair use to be kept (or is it {{PD-shape}}?)

Why this cleanup is worth doing?

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

Questions

1. How long we should wait between notifying uploader and deleting the image? 2 months? 4 months? 1 month?
2. Is it desirable to delete old irreplaceable images with unclear licensing status uploaded by OSM mappers? For example photos of OSM events?
   1. If such images would be kept - how to specify rules to block further uploads without a clear status?
3. Is it OK and desirable to have some fair use images? On which rules?
4. Have I missed some category of images?
5. Is it OK to upload "noncommercial use only images"? This is problematic as it is not really clear which use is forbidden, severely restricts reusability and so on. Wikimedia Commons is not allowing such images for quite good reasons
6. Would it be OK to allow user-page only personal images that are not openly licensed? See User_talk:Nacktiv
7. Template:Maxar image - Are we allowed to use Maxar imagery such as https://wiki.openstreetmap.org/wiki/File:Ford_line.jpg for illustration on wiki? If yes - why and how? (it is not covered by editing permission - "you understand and agree that you may only use our imagery to trace, and validate edits that must be contributed back to OSM. You cannot download our imagery or use our imagery for any other purpose" - Maxar
8. Template:Bing image - Are we allowed to use Bing imagery for illustration on wiki? If yes - why and how? (it is not covered by editing permission - "The rights that you have under this agreement are limited solely to aerial imagery use in a non-commercial online editor application of OpenStreetMap maps (an "Application")." - Bing Maps)

Mateusz Konieczny (talk) 02:36, 9 December 2021 (UTC)

Extra questions (added later)

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

Discussion

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

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

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

@Maro21: "6 months" That is for old images, right? What about brand new upload where user was notified within days from upload? Would it be OK to have shorter time there? Mateusz Konieczny (talk) 08:14, 10 December 2021 (UTC)

I assume that in such cases they will react, answer and add a license sooner than later ;p. Otherwise yes, shorter time would be ok, 1 month? maro21 16:45, 11 December 2021 (UTC)

IMHO 3 months for old ones is OK, but I'm also fine with 6 months. For new ones, if uploader is notified in same week (within 1 week) then 1 week time limit from moment of notifying should be adequate. If within 2 weeks then +2 weeks. Within 1 month then 1 month. - What about this proposal: If image file is uploaded without selecting a license, there will be automatically added a template that indicates there is no license and sets a time limit (e.g. 2 weeks) for deleting the file? --Chris2map (talk) 19:16, 11 December 2021 (UTC)

@Maro21: "I assume that in such cases they will react, answer and add a license sooner than later" - at least some are no longer active, sometimes for 10 years and more. We have large enough project that some left completely (sometimes due to lack of further interest, some were banned and some died) Mateusz Konieczny (talk) 08:08, 12 December 2021 (UTC)

I meant recent uploads from active users, that they will react sooner so 6 months period won't be necessary. maro21 21:56, 12 December 2021 (UTC)

3 - Are screenshots of websites such fair use images as long as they are used as previews in descriptions or lists of the website service and the service relates to OSM in some way? (e.g. List of OSM-based services) --Chris2map (talk) 19:02, 28 December 2021 (UTC)

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

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

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

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

It is worse! "this file can stay since it was first posted to Pixabay prior to 9 January 2019" - but it was uploaded to OSM Wiki after that, so it was almost certainly obtained on restrictive license (it does not matter that it was earlier available on more permissive one, though maybe getting it from internet archive page of old versions is still possible?) Mateusz Konieczny (talk) 16:00, 17 June 2022 (UTC)

Could that serve as an alternative source https://www.maxpixel.net/Massachusetts-Cape-Cod-Ocean-Salt-Marsh-Nature-2763723 ? The website itself carries "(c)2016" in footer. They state that they couldn't guarantee for the permission, but who can? (Can we be sure in every case on Commons?) --Chris2map (talk) 17:15, 17 June 2022 (UTC)

copyright violations that needs replacement

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

Generally editable part

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

You can help by following:

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

Once file is not used anymore

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

Files:

• https://wiki.openstreetmap.org/wiki/File:Gereja.png (license unknown, uploader notified in December 2021)
• https://wiki.openstreetmap.org/wiki/File:Organized_camp_aerial.png (license unknown, uploader notified in December 2021, maybe image should be simply removed)
• https://wiki.openstreetmap.org/wiki/File:Step_contrast.jpg (In use, needs replacement or tracking down source, see https://wiki.openstreetmap.org/w/index.php?title=User_talk:PanierAvide&curid=117019&diff=2337099&oldid=2335828)

For files without replacement:

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

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

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

Migrate taginfo to AJAX-based rewrite

Please comment on this proposal to replace {{Taginfo}}'s implementation with {{Taginfo2}}. A migration was previously discussed but the discussion was inconclusive. – Minh Nguyễn ^💬 21:24, 2 January 2022 (UTC)

Dubious licensing of a derivative work

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

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

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

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

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

Current list is as follows:

• https://wiki.openstreetmap.org/w/index.php?title=File:Autobahnanschluss_grosskugel.png&curid=28522&diff=2253157&oldid=2251967
• https://wiki.openstreetmap.org/w/index.php?title=File:Braided-streets-example.jpg&curid=14555&diff=2254083&oldid=2254065
• https://wiki.openstreetmap.org/w/index.php?title=File:2008-10-30_155254.png&curid=24489&diff=2251813&oldid=2251369
• https://wiki.openstreetmap.org/w/index.php?title=File:Bus_platform.png&curid=65803&diff=2256092&oldid=2254308
• https://wiki.openstreetmap.org/w/index.php?title=File:CH-Zusatztafel-5.18.jpg&curid=264192&diff=2254392&oldid=2254334
• https://wiki.openstreetmap.org/w/index.php?title=File:TrackVsStreet.png&diff=2276065&oldid=2275892
• https://wiki.openstreetmap.org/w/index.php?title=File:R_kleineisel_6.png&curid=30047&diff=2296538&oldid=2296489 (File:R kleineisel 6.png claims that uploader is the author, what is dubious at best)

--

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

Forbidding upload of new files using outdated Creative Commons license?

Related to Talk:Wiki#Designing_policy_for_handling_files_without_clear_license

See https://doctorow.medium.com/a-bug-in-early-creative-commons-licenses-has-enabled-a-new-breed-of-superpredator-5f6360713299 for description of the problem.

I propose to follow their recommendations and to

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

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

Thanks for discovering! I think we should regard that. At least prohibit uploads and enhance the templates. --Chris2map (talk) 20:25, 14 March 2022 (UTC)

What about this text for the "-self" templates? Dear author! This version of the CC license is outdated. Please consider updating to latest version 4.0 to avoid legal hassle. (Learn more). Maybe we should create a wiki page with infos and link to it. --Chris2map (talk) 21:35, 14 March 2022 (UTC)

I agree with you, I think that users should be encouraged more clearly to indicate the license of the imports properly. But I would be in favor of giving them a minimum time to react (like 1-2 weeks) — Koreller (talk) 06:40, 25 May 2022 (UTC)

Can you license OSM-based map as CC0?

For example in https://wiki.openstreetmap.org/w/index.php?title=File:Early_UK_coverage_growth_2005-2007.gif&curid=5339&diff=2276626&oldid=2276504 I suspect that CC0 may be applied to additional creative work if any, but OSM data will be still licensed as Template:CC-BY-SA-2.0 OpenStreetMap (note dates) Mateusz Konieczny (talk) 10:54, 7 March 2022 (UTC)

In my opinion, work with OSM data under CC-BY-SA-2.0 could only be licensed "alike" under same license, so CC-BY-SA-2.0 and not CC0. ("ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.") --Chris2map (talk) 20:29, 8 March 2022 (UTC)

Graphical improvements to the Wiki

Hello, I noticed that the interface of the wiki was not very adapted to the mobile and that some formatting was not very ergonomic.
For that I would like to recast some pages in particular with the following formatting models:

• {{Clickable button}}, {{Colored box}}, {{Colored rule}}, {{Colored bar}}, {{Begin colored insert}}

And I will use those icons (and especially OOUI icons), combine with some responsive code.
I started to do some graphic redesigns like here : Develop or there : Get help (Tab system), or there : Use OpenStreetMap, or there : Template News (see also the topic for the simpler, more accurate and accessible system for accessing external files that are hosted on Commons)
Do you see any reason not to do so ?
Thank a lot and have a good day ! — Koreller (talk) 23:59, 12 March 2022 (UTC)

Are the templates your own work or are you copying another wiki? --Andrew (talk) 22:03, 13 March 2022 (UTC)

Hello, these templates have been copied from other wiki (mainly from Wiktionnaire FR and Wikipedia FR), and it is sometimes me who created them on these other wiki. I updated the documention page of those template to put the origin of it — Koreller (talk) 07:03, 15 March 2022 (UTC)

Could we adapt this a bit more to the OSM designs as shown on https://osmfoundation.org or https://osm.org? The icons and colors reflect the design guide of Wikimedia Foundation but OSM is not a part of it. Additionally, I think that Template:HelpMenu looks good but it does not match the visualisation of the card index style the template used to have before. The homepage uses Bootstrap and Flex. Some years ago, I used icons by The Noun Project when updating templates. --Tigerfell  (Let's talk) 12:55, 16 March 2022 (UTC)

Of course ! You totally right, so I will try use more icon from c:Category:SVG icons from The Noun Project.

Furthermore I try to change the Template:Colored bar to looks more like https://wiki.osmfoundation.org/wiki/Main_Page, what do you think about this ?

Also, does the foundation have any graphic guides? (It would help me a lot to not just copy the Wikimedia foundation's graphic guides) — Koreller (talk) 15:41, 16 March 2022 (UTC)

I could not find any. User:Tigerfell/User interface holds a compilation of currently used styles in templates. It is a bit chaotic because people just copied stuff from other wikis. I did not include every template but just the basic ones. The commonly used templates reference these templates in return. Template:Colored bar looks good! --Tigerfell  (Let's talk) 14:06, 17 March 2022 (UTC)

Develop does now indeed work better on mobile, that's a clear improvement! Would it be possible to make the green boxes on the Main Page vertically stacked on mobile as well?

As for the aesthetical changes, I'm not convinced that all of them are improvements. In particular, I believe that styling small links such as Template:Main as a prominent box that runs across the entire width isn't ideal. IMO, the border and different background serve no clear purpose here, the icon and indent already make the link sufficiently noticeable for the reader.

At Get help and other pages using Template:HelpMenu, I'm afraid the new design may degrade usability: There is no indication to the user about the purpose of these boxes as they do not look even remotely like tabs. (And visually, I would prefer not to have a colored box behind the main content of the page.)

--Tordanik 21:54, 16 March 2022 (UTC)

So I cancelled my changes. As a result, some pages are no longer easily viewable on mobile and as a mobile user of the wiki it's not so good — Koreller (talk) 22:04, 16 March 2022 (UTC)

Main page: You could split the used tables and add floating to allow mobile devices view the boxes one below the other instead of side by side. I made a test here: Test of floating Main page --Chris2map (talk) 15:10, 18 March 2022 (UTC)

There was a different proposal recently at Talk:Main Page#Improving mobile view. Please file requests there. --Tigerfell  (Let's talk) 10:49, 25 March 2022 (UTC)

I think it is time to re-style a lot of the message boxes derived from Ambox and navigational templates to give them a more OSM-like look. Unfortunately, there are many templates that are not used very frequently and they are not documented or listed so the users create new ones whenever they need them. As a first step, I overhauled Wiki organisation#Labels to document useful message boxes regarding the wiki cleanup efforts. --Tigerfell  (Let's talk) 10:06, 3 April 2022 (UTC)

What is "OSM-like look"? :) maro21 10:22, 3 April 2022 (UTC)

As I wrote above already, there is no exact OSM design guide. I would suggest to copy the design of osm.org and wiki.osmfoundation.org. Images could be used form the homepage or The Noun Project (TBD). --Tigerfell  (Let's talk) 12:32, 3 April 2022 (UTC)

IMHO if so, the wiki should be based on OSM/OpenStreetMap.org. But there isn't very much design to copy for the wiki. I am against copying from foundation. I think OSM wiki should be clearly distinguishable from foundation pages and personally I don't like the foundation page design that much. I don't think the current wiki is that bad. We could pay a little more attention to creating uniform boxes and updating old boxes. --Chris2map (talk) 20:07, 3 April 2022 (UTC)

I created Template:Wfmessage similar to Template:Mbox but based on the colors of the OSM web page. I think they are a bit too strong. I already tried to color the borders instead of the backgrounds for some types of messages, but I guess I need some input from others ... --Tigerfell  (Let's talk) 17:12, 24 April 2022 (UTC)

I continued with Template:Wflicence which should become a meta template for media license templates. Happy to hear your feedback. --Tigerfell  (Let's talk) 19:37, 15 May 2022 (UTC)

Follow up on Template_talk:Wflicence... --Chris2map (talk) 21:12, 16 May 2022 (UTC)

Automate obvious part of "Image superseded by Wikimedia Commons"

There is Category:Image superseded by Wikimedia Commons which contains files which should be replaced by Wikimedia Commons files. I propose to automate replacement where image use

• is being displayed with a specific size or where file size is the same (to avoid situation where image is displayed as much larger after the edit) - edits would look like this one
• is being used as infobox parameter - edits like this one

Additionally, if image is no longer used it would be marked for deletion.

Following would be still handled manually

• confirming that file is an exactly the same image, maybe with lower resolution (and not just very similar - that requires manual checks during replacing)
• cases where image would be now displayed with a changed size

Code was tested in manual operation, I expect it to work well without supervision (after limiting to only safe edits)

Mateusz Konieczny (talk) 09:20, 22 March 2022 (UTC)

And the question: is it a good idea to edit file use also on talk pages with such bot? Mateusz Konieczny (talk) 09:26, 22 March 2022 (UTC)

I mean talk pages should rather not be changed. --Chris2map (talk) 21:19, 24 March 2022 (UTC)

In such case we have some options (1) accept talk pages with dead images (2) accept archived talk pages with dead images (3) we need volunteers to maintain pointless duplicates (licensing info etc is missing for most Category:Image superseded by Wikimedia Commons) Mateusz Konieczny (talk) 22:16, 24 March 2022 (UTC)

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

Hello everyone,

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

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

The Media Viewer extension aims to:

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

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

Thanks for your answers — Koreller (talk) 09:14, 23 March 2022 (UTC)

Can you give examples of specific files and actions where it would be helpful?

I think that smarter solution would be moving files to Mediawiki Commons, we are unable to handle existing ones. Note that downloading, viewing files is possible already Mateusz Konieczny (talk) 11:22, 23 March 2022 (UTC)

@Mateusz Konieczny: The Media Viewer is orthogonal to where the images are hosted. It works just as well with images hosted on Commons. The interface looks a little different for such images, as you can see when previewing most images on Wikipedia. – Minh Nguyễn ^💬 21:06, 14 April 2022 (UTC)

Once this extension is installed, will it be possible for anyone to disable it? maro21 18:59, 23 March 2022 (UTC)

@Maro21 Yes, you just click the settings button in the upper right of the image viewer when an image is shown and click "disable". Lectrician1 (talk) 22:22, 23 March 2022 (UTC)

 Support Lectrician1 (talk) 22:23, 23 March 2022 (UTC)

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

EWG projects to improve wiki software

The Engineering Working Group is attempting to improve OSM's software infrastructure with funding for moderately-sized open source development projects. As part of this effort, we're also looking at the wiki:

• Are there desirable improvements to the OSM wiki that are not possible with existing configuration options or plugins and would therefore require some software development?
• If we decide to invest in improving the wiki software, where do we find competent developers for MediaWiki projects?

We would welcome your input as active wiki contributors! --Tordanik 09:28, 3 April 2022 (UTC)

That sounds great!

There are a lot of requests for configuration changes to the wiki. Note that there is a general wiki configuration for this wiki as well as all wikis of the working groups and a separate one for this wiki, so changes might effect all MediaWiki instances. There are also some pull requests ready to be merged into the configuration. However, they are not merged and feedback information is rather rare. If you want to improve that situation, you would need to get in touch with OWG and find out the issue. IMHO that is either that they do not have the capacity to review such changes or they think we open to many requests.

If you want to have more specific projects, I can name two from the top of my head

1. Unify wiki and homepage accounts: First, find out if the involved parties (i. e. OWG on the configuration side and wiki administrators on the administrative side) still favor this. Second, evaluate technical solutions and decide for one (some software engineering might be necessary). Third, document processes for account transfer/renaming/merging/... as well as account termination and user name changes. Forth, get the new configuration merged. Lastly, some minor support for user and administrator inquiries for a limited time (might not be necessary if documentation (3rd step) is good).
2. Updating MultiMaps MediaWiki extension (project work board): the maintainer has stopped maintaining the extension. Some security updates are added via MediaWiki maintainers but that is probably insufficient to maintain the extension in the longer term (i. e. that it will still work with MediaWiki in five years). That would include updating Leaflet to a recent version and other tasks on the project work board. First, you probably need to find a new maintainer so that they will get access to the code. Second, you would need a code reviewer. Fortunately, those changes are bug fixing, improving unit tests, and dependency updating and therefore uncontroversial. This does not involve a configuration change on OWG's side, because their configuration always uses the same version of the extension as the MediaWiki version. So, when OWG updates MediaWiki, MultiMaps extension will be updated, too.

I have never tried to acquire competent developers, but if you have a financial budget you can have a look at the Jobs page on mediawiki.org. Additionally, I might be able to help out with questions regarding the interplay of the configuration and MediaWiki or some code reviews.

Hope this helps. --Tigerfell  (Let's talk) 11:13, 3 April 2022 (UTC)

For start, reviewing and merging/rejecting https://github.com/openstreetmap/chef/pull/462 and https://github.com/openstreetmap/chef/pull/400 would be great. And I want to concur that most of issues are listed already, especially https://github.com/openstreetmap/operations/issues/507 https://github.com/openstreetmap/operations/issues/373 https://github.com/openstreetmap/operations/issues/383 https://github.com/openstreetmap/operations/issues/449 https://github.com/openstreetmap/operations/issues/573 https://github.com/openstreetmap/operations/issues/466 Mateusz Konieczny (talk) 07:12, 5 April 2022 (UTC)

Just for reference, there was an EWG meeting the day after this was posted. Their minute does not make a lot of sense however. --Tigerfell  (Let's talk) 11:58, 26 April 2022 (UTC)

Thank you for the feedback so far and especially for offers to help! Just to clarify: Pure configuration changes (and merging the related pull requests) are firmly in operations territory, so they're unfortunately out of scope for EWG. But account unification and updating the multimap extension sound like tasks that the EWG could play a role in. I'll bring these to the EWG's attention. @Tigerfell: If the EWG wants to know more about the challenges involved, would you be willing to participate in an EWG meeting on the topic?

To explain the minutes: Considering the repeated discussions about the Translate extensions (and its shortcomings), the EWG has been wondering if improving that extension could be another wiki-related engineering task. Do you believe that the problems identified with the current Translate extension could be resolved by a developer substantially improving it (or even forking it and changing the way it works, e.g. regarding non-English pages, the requirement to have markup on the original page, and other drawbacks that have been criticized in the past)?

If anyone has additional ideas, please keep them coming! --Tordanik 15:21, 10 May 2022 (UTC)

If the EWG wants to know more about the challenges involved, would you be willing to participate in an EWG meeting on the topic?

Okay. I would be able to make it on the 6th June for instance.

Thanks for the clarification regarding EWG's plans on the translate extension. I am not really into the discussion but skimming over the opposing votes the main objection was missing support for language-specific content. I am not sure if you can modify the extension such that it will not rely on the markup anymore. The software needs to detect which parts of the page have been changed. One could use the headlines for that but the smaller the pieces the less text is marked as outdated because something else in this part was changed.

The rest is an IT strategy question I guess. The more you move away from standard software maintained by others the more you have to do by yourself. As a result, you have higher maintenance cost but also a better fit regarding your needs. Consequently, if a modification of translate extension were developed and the maintainers of the core extension do not want to include and maintain the feature EWG will need to maintain it. EWG would need to allocate part of its budget at least bi-annually to the maintenance. Sorry, I can not provide any figures here because I lack experience. It is like owning a house: at least you need to check if repairs are necessary. In conclusion, I would say that changing the translation should be possible but the cost of maintaining it over years might completely outweigh it.

To get some more qualified statements, you could reach out to Harry Wood (author of Slippy Map MediaWiki Extension, the predecessor of MultiMaps extension in this wiki) or Yuri Astrakhan (author of the modified Wikibase extension used in this wiki). --Tigerfell  (Let's talk) 19:28, 15 May 2022 (UTC)

The Translate extension itself is a good tool. The problem is not in the code of this extension, but:

- the lack of people to translate

- the fact that many things in the 17 years that the Wiki has been around have already been translated

- the amount of work and man-hours that would be involved in transferring pages to the new format

- the fact that the extension is good for translating short messages, not long articles like in Wikipedia. maro21 20:46, 18 May 2022 (UTC)

Flags and separators in osm calendar

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

@Dieterdreist: I agree, some kind of visual indication or filter on the main page would make the global event listing more usable. In the meantime, individual country pages can embed filtered OSMCal listings, for example United States#Upcoming events. Hope this helps! – Minh Nguyễn ^💬 20:21, 7 May 2022 (UTC)

I also preferred the old visual presentation and agree that the current "wall of text" is not ideal. To me, issues include:

• The lack of structure/whitespace
• No flags (which are useful because they let me visually scan a list for events that have a good chance to be near me and held in a language I understand)
• Poor-quality automatic generation of place descriptions. A human would not have written "Berlin, Berlin, Germany" or included a city for an event that happens online.
• Too much text (caused by unabbreviated names of months, country names instead of flags, and the automatic place descriptions)

--Tordanik 15:00, 10 May 2022 (UTC)

One of the challenges here is that the formatting is exclusively managed in an external dependency without much options to influence it using Wiki templating or Lua code. Extensions like https://www.mediawiki.org/wiki/Extension:External_Data provide much better options to customize external data presentation in a wiki. As it's a stable extension, it would also be one less of a dependency to maintain on our own. Mmd (talk) 13:47, 3 June 2022 (UTC)

Mobile frontend UI - appearance of mobile view

Hi! If you are interested in "improving" the appearance of the mobile view of the wiki, I invite you to check out Wiki_talk:Mobile view. From my side, I see room for improvement in terms of colors, style sheet support and the content of the main menu. --Chris2map (talk) 17:12, 29 April 2022 (UTC)

I added a topic on responsive tabs — Koreller (talk) 16:11, 16 May 2022 (UTC)

Mediawiki internal error with Recent changes

Unresolved

I can't filter recent changes and choose one namespace, for example talk pages because there is an error "[3d0a0d00d2a4fab30d951498] 2022-04-30 16:54:28: Fatal exception of type "TypeError" :/. maro21 16:55, 30 April 2022 (UTC)

I can not confirm. Everything works for me. Strange! --Chris2map (talk) 17:08, 30 April 2022 (UTC)

What do you see when you click the link? maro21 18:06, 4 May 2022 (UTC)

It errors for me. What about https://wiki.openstreetmap.org/wiki/Special:RecentChanges?hideWikibase=1&namespace=1&limit=500&days=7&enhanced=1&urlversion=2 which works fine for me? I created it from https://wiki.openstreetmap.org/wiki/Special:RecentChanges Mateusz Konieczny (talk) 20:09, 4 May 2022 (UTC)

@Maro21: Sorry, I didn't recognize and check your first link! Same error for me. Is this a valid url? Did it work earlier? I had checked the function on Special:RecentChanges page and all works there (also link of Mateusz). --Chris2map (talk) 20:32, 4 May 2022 (UTC)

It worked before. This is how I checked recent changes in the past: Special:RecentChanges and then I chose namespace and clicked "Show". maro21 20:41, 4 May 2022 (UTC)

@Maro21: I'm still not clear where this URL notation of your first link that causes an error is generated / used. But I could explore the following: With /w/index.php?namespace=1&tagfilter=&users=&title=Special%3ARecentChanges the option &users= should not be empty. Either remove it from the URL (test1) or put in an user name (test2). Does this do it? --Chris2map (talk) 15:44, 15 June 2022 (UTC)

The manually edited link obviously works, but I would like the whole thing to work. When I select another namespace from the list from the working URL, there is still an error. Good that you at least found what causes the error and that removing "users=" fixes it - so I can create links like Talk pages, Templates etc. maro21 22:39, 15 June 2022 (UTC)

Fine, I checked your new links and they work for me, even if I change namespaces. But why do you use this form of url notation? Why don't you use https://wiki.openstreetmap.org/wiki/Special:RecentChanges?namespace=1 ? --Chris2map (talk) 07:58, 16 June 2022 (UTC)

I don't use the URL. I use the RecentChanges tool, which generates such a URL. maro21 23:58, 25 June 2022 (UTC)

Redundant pages for "building block" tags

Conditional restrictions is a building block system for road rules, such as maxspeed=*, maxweight=*, access=*, oneway=* and many others. The main benefit is that you don't need to invent a tag for every rule that might occur; instead, the meaning of a tag is clear from its basic building blocks.

So imagine my surprise when I discovered people had started creating wiki pages documenting keys such as Key:maxspeed:hgv:forward and Key:maxspeed:hgv:backward.

The number of possible combinations is easily in the thousands (dozens of base keys × dozens of vehicles they can apply to × forward/backward/both). These pages add no meaningful information as the meaning of the tags is determined by following well-documented rules. They create a significant maintenance burden, make every future change more costly as more pages need to be changed, and make it far too easy for differences and contradictions between the pages to creep in over time.

Of course, the same applies to other "building block" tagging systems, such as the combinations of (alt_name, old_name, ...) × (en, de, fr, es, it, ...). I'd like to update the wiki guidelines to explicitly state that such pages should not be created. I'm aware that this relates to a larger discussion on when to create or not create tag documentation pages, but I'd like to focus on the particularly extreme example of "building block" tags first. --Tordanik 07:40, 19 May 2022 (UTC)

I strongly disagree. Yes, if you are already aware about tagging scheme then separate page about a specific tag variant adds little to no benefit. But for someone encountering tag for the first time tracking down what it means, where it is defined and how it should be treated is daunting if it has no specific tag page and mapper is supposed to decode it into segments, find pages then track down where this specific aspect is described. If you are for example implementing support for parking lanes then having separate page for parking:condition:left:maxstay=* confirming its status is useful, even if that info can be reconstructed from trawling through several other pages. You propose to delete Key:lanes:both_ways and Key:turn:taxi:lanes and Key:name:pl and Key:oneway:bicycle and Tag:cycleway:both=no and Tag:vehicle=no and Tag:maxspeed:type=PL:urban pages and merge them into some superpages. I already linked this pages multiple times to people looking to solve tagging issues. Linking massive superpage "every single detail about turn lanes" would be an inferior solution to linking Key:turn:taxi:lanes when user asks about special turn allowance for taxis Mateusz Konieczny (talk) 07:50, 19 May 2022 (UTC)

I am quite good at understanding OSM tagging but I still needed noticeable time to track down Key:turn:taxi:lanes and confirm that it is valid - and I created this page after doing this. I see no value at all in deleting it. "add no meaningful information as the meaning of the tags is determined by following well-documented rules" strictly speaking may be true, but expecting all users to recreate this info from scratch is worse than having one more page. And I disagree with "well-documented rules". Someone encountering Key:maxspeed:hgv:forward for the first time will have a lot of trouble to reconstruct its meaning and track down where it is defined, if page explaining it will be deleted Mateusz Konieczny (talk) 08:02, 19 May 2022 (UTC)

"They create a significant maintenance burden, make every future change more costly as more pages need to be changed" - which kind of change you mean? Tag deprecations? Here OSM Wiki pages are smallest part of the problem anyway Mateusz Konieczny (talk) 07:50, 19 May 2022 (UTC)

Note: some previous and parallel discussion is in https://community.openstreetmap.org/t/wiki-page-for-each-tag/1471 Note that discussion outside wiki has much lower, if any, impact on OSM Wiki rules Mateusz Konieczny (talk) 08:04, 19 May 2022 (UTC)

This isn't Wikipedia, there is no notability test. If someone wants to write documentation for a particular key or value then they should be allowed to. The only thing I would ask for is that the page should link back to the "parent" so users can follow it for further information. Adavidson (talk) 10:12, 19 May 2022 (UTC)

"The number of possible combinations is easily in the thousands (dozens of base keys × dozens of vehicles they can apply to × forward/backward/both)" - it is not so bad. For example speed limit specific to a given vehicle type are pretty limited - see transport modes. Vast majority of them is not having own specific speed limits. Mateusz Konieczny (talk) 08:11, 19 May 2022 (UTC)

"I'd like to update the wiki guidelines to explicitly state that such pages should not be created" - can you create list of pages which would be deleted (turned into redirects) via this new rule? Mateusz Konieczny (talk) 08:15, 19 May 2022 (UTC)

@Tordanik: Key:turn:taxi:lanes Tag:maxspeed:type=PL:urban Key:lanes:both_ways Key:name:pl Key:maxspeed:hgv:forward Key:oneway:bicycle - are you proposing to delete this pages? Redirect them? Where content present there would be moved? Or do you think that it should be deleted as useless? Mateusz Konieczny (talk) 12:02, 19 May 2022 (UTC)

@Tordanik: You proposed deletion of several or hundreds of pages. Can you clarify what you are proposing to delete and and what would happen with content present there? Without making this clear this proposal should not be treated seriously Mateusz Konieczny (talk) 07:07, 26 May 2022 (UTC)

I don't have a lot of zeal about deleting existing pages, just trying to make sure that (what I perceive as) a problem does not spread. The examples you list are quite different: Key:maxspeed:hgv:forward is indeed a page that I consider to add nothing beyond what's already available elsewhere. Key:oneway:bicycle normally would be just as redundant, but there's enough historical baggage related to its coexistence/overlap with cycleway=* values that I can see good reasons for creating the tag. Tag:maxspeed:type=PL:urban isn't an example of a building block tag. And Key:name:pl should be redundant, but I'm not sure if there's already a good explanation of language suffixes somewhere that it could redirect to. --Tordanik 12:55, 27 May 2022 (UTC)

@Tordanik: Just to clarify, these other "building blocks" can't necessarily be subsumed by the conditional restrictions syntax, though in a few cases they might've had history turned out differently. I agree that it isn't especially productive to create a dedicated page for each permutation of these schemes – or a data item, for that matter. Unfortunately, some tools essentially require a dedicated page for some functionality. For example, taginfo will only show a key as documented if it can find a page by literally that name, and iD will only display documentation about a key if there's a data item corresponding to that exact key. A fix for this taginfo feature request might come with enough smarts to find the correct base key for any subkey. In the meantime, perhaps MediaWiki:Noarticletext could be enhanced with some base key–finding functionality. – Minh Nguyễn ^💬 08:27, 19 May 2022 (UTC)

I strongly disagree that pages like Key:maxspeed:hgv:forward and Key:maxspeed:hgv:backward should not be allowed to exist. There are many different niche tags in OSM and the Wiki exists to document and explain all of them. If people wish to write more elaborate documentation than what is documented in a table somewhere in the page of a more commmon key like access or maxspeed, I would be very happy. This follows ATYL, one of our most fundamental principles. I also would not accept anyone's authority for deciding which tags are allowed and disallowed to be documented. --501ghost (talk) 08:42, 19 May 2022 (UTC)

@501ghost: Perhaps I should've been explained what I meant by MediaWiki:Noarticletext: that's the message that shows up whenever you visit a page that doesn't exist. Similarly, MediaWiki:Newarticletext appears when you follow a redlink, and MediaWiki:Searchmenu-new appears above search results. We could add something to these messages so that, when you look up "Key:maxspeed:hgv:forward", you get a list of links to maxspeed=*, hgv=*, and forward=*, along with descriptions about these key parts from the respective data items. (Unfortunately, it would be infeasible to scrape these descriptions from infoboxes.) If some combination of subkeys has an unintuitive meaning that wouldn't be adequately described by this list, of course a page can be created for it. But this automated message would keep us from having to create a page for every combination. – Minh Nguyễn ^💬 08:54, 19 May 2022 (UTC)

That would be a good thing for many cases! Though there would be two problems to solve (1) avoid showing this info for tags not actually used or not making sense at all or having a different preferred tagging scheme. (2) pages like Key:turn:taxi:lanes Tag:maxspeed:type=PL:urban Key:lanes:both_ways Key:name:pl Key:oneway:bicycle which have some extra info should be allowed to be created (3) I suspect that custom text would be likely needed to make clear what is happening with decomposition of tag into parts rather than using text from infoboxes (directly or via data items). Mateusz Konieczny (talk) 09:24, 19 May 2022 (UTC)

These niche tags do deserve to be documented, but I don't believe a separate page is the best solution for every tag. It is much easier to document, understand, and discover tags when structured so that there are fewer separate pages with more content, rather than more separate pages with each less. Unless there is a good reason why the page needs to be split from the "main" tag article, it is much better to enrich the parent document. Diacritic (talk) 11:30, 19 May 2022 (UTC)

Interesting. For me basically always I need wiki documentation after (1) encountering specific tag on some object (2) specific tag was linked in other part of documentation (3) I am looking to represent something specific (4) I want to link it as explanation how something can be mapped. In all this cases having dedicated page for key/tag is superior to some large overview. For example in case of someone asking "how to mark Polish name abroad" linking Key:name:pl is much more effective than linking Names and hoping that user will figure it out (that is why I created this page, someone found Names and was still confused). The same goes for example when I encounter name:ko=* - specific page would be helpful to quickly establish meaning (and potentially things specific to this language and mattering in OSM tagging) rather than reconstructing it. Or having Merged page describing all language specific name tags in detail (note: I edited name:ko link to direct to Multilingual names which makes it less confusing, though you still need to search for it in page) Mateusz Konieczny (talk) 12:13, 19 May 2022 (UTC)

@Diacritic: - where you would move content currently placed on Key:lanes:both_ways? Do you think that part of it should be deleted? Mateusz Konieczny (talk) 12:17, 19 May 2022 (UTC)

@Diacritic: - where you would move an example from Key:turn:taxi:lanes? Or would you delete it? What would you do with Key:turn:taxi:lanes - delete it? Redirect? Mateusz Konieczny (talk) 12:20, 19 May 2022 (UTC)

Hey @Mateusz Konieczny: - a "good reason" for having a separate page from the main tag article is obviously subjective, but the names tag is a pretty good example to bring up! While there is too much content on the application of name tags for a single article, there are:

• Names
• Multilingual names
• Key:name
• 30+ language-specific name keys
• Specific country tagging documents.

There is a lot of useful content in many of these pages, but it can be difficult for a new reader to grasp the "whole". Many language specific subtags are useful and have unique content (name:vi=*), but many others are essentially the same article with no real reason to exist as a separate page. (cf. name:ar=* vs name:hop=* vs name:oc=*, or official_name:en=* vs official_name:fr=* vs official_name:ru=*)

These pages may well be expanded at some point in the future, but I feel the best strategy would be to enrich an existing page (maybe, cleaning up Multilingual names a bit, including a table of language codes?) until there is enough content to justify "splitting". In the examples you've given, I'd personally move the content of lanes:both_ways=* and merge it into the Key:lanes#Lanes_in_different_directions section - the examples could be integrated fairly well, and the text of the independant page and the text of the section have the same subject and purpose.

For Key:turn:taxi:lanes, the example would seem to fit Key:turn#Special_turn_indications_for_specific_vehicle_types. By putting the taxi example there, you could also effectively document Key:turn:psv:lanes and Key:turn:bus:lanes as well; maybe even with an additional example which includes both! Redirects are easy to maintain and would help direct users to the appropriate page. I think they should be used where we currently would leave a red hyperlink to a page that doesn't exist. Diacritic (talk) 21:15, 19 May 2022 (UTC)

@Minh Nguyen: A tool-based solution would be welcome! :) For example, I like that the Tag template already supports keys consisting of multiple components instead of assuming that there will be a page for each combination. And yes, I mentioned conditional restrictions as just one example of a "building block" approach for tags, clearly there are other such systems in use as well.

Because of the response by Mateusz, I'd also like to talk about the costs of duplication some more. To me, these include:

• Cost of updates. While I obviously cannot predict how our tagging standards will change in the future, I think it's safe to say that we haven't reached a perfect data model with no room for improvement. In the best case, having to change content on multiple pages means more work (and that's bad enough). But it's quite likely that we will instead forget to update it somewhere.
• Overwhelming amount of content. It forces a diligent reader (e.g. someone who wants to implement an OSM-based router) to study all these pages. While most such pages will just duplicate information found elsewhere, other tag pages contain unique information, and there's no way to tell these apart without first reading them.
• Lack of oversight. Few or no users have these pages their watchlist. So if you make a mistake in creating or editing them, it's possible that it won't be noticed until years later (when the contradictions will already have caused problems in the database).

--Tordanik 10:44, 19 May 2022 (UTC)

1. In case of redefining tags updating wiki pages is vanishingly small part of all costs. Also, in case of changing standards such pages become more useful as it makes possible to describe tags as outdated/replaced without having all that documentation of page of actually used tags.
2. Overwhelming amount of content goes in both direction, Bicycle is overwhelming already without trying to merge several more tag pages there. Trying to find meaning of specific tag from it as a new user is problematic. And in some cases even ctrl+f search for tag is not going to help, as it is not mentioned by name! And after merging in all this pages you want to delete it would grow even more, and plenty of extra info would need to be deleted to keep it sane
   • "It forces a diligent reader (e.g. someone who wants to implement an OSM-based router) to study all these page" - I am one of such people. Looking through Wiki is the easiest part and least costly, and I never had problem with that. And while encountering contradictions is irritating it is still better than having only one variant/style being documented. Seriously, I never had "I wish that this composite tag would be not documented and I will have fun with tracking down definition of its segments" reaction
3. "Lack of oversight" - having all changes having in superpage also makes problematic to follow what even is being changed. Also, having all detail being described on few pages would make things quite hard to follow. Though it is also a solvable problem. Maybe submit to OSM Weekly list of recently created documentation wiki pages? List them somewhere? BTW, Special:NewPages exists.

Mateusz Konieczny (talk) 11:57, 19 May 2022 (UTC)

I think there's nothing wrong with creating documention for every used and popular (but popular, not syntactically possible and almost not used) tag, but: the documentaion of the dependent key or tag (like Key:maxspeed:hgv:forward) should have more information than a superpage (Conditional_restrictions in this case) has about this key or tag and there should be a link to this page. maro21 21:48, 21 May 2022 (UTC)

One upside to creating a separate page for each compound key (and its values) is that taginfo will scrape that page for its description, image, and applicability to each element type. Taginfo's maintainer has so far declined to fetch this information from data items, so currently taginfo carries only a subset of the information visible to ordinary mappers on this wiki or in iD. – Minh Nguyễn ^💬 23:03, 28 May 2022 (UTC)

Enhanced not-found messages

@Tordanik: I cobbled together something quick that you can try out by following a redlink like construction:turn:lanes:both_ways=*, description:hazard:it=*, or source:destination:forward:mapillary=* or going to [7] directly. It lists a component if there's a description page, data item, or recognized language code by that name. Aggressive creation of redirects and data items results in some components that lack descriptions, but this is individually fixable. The presentation can be improved in Template:Noarticletext, and so can the key parsing logic in Module:Tag. It would be possible for the algorithm to match components less greedily at some cost to performance. Localization isn't working perfectly either. Along the way, I also replaced the existing {{Taginfo}} box with a full infobox, just like you'd see on a real tag description page, but powered by a data item as long as that information is available. – Minh Nguyễn ^💬 04:59, 20 May 2022 (UTC)

Really, really nice! But it is now fully clear that we need a custom descriptions - "construction" as lifecycle prefix has distinct meaning from "construction" as a tag Mateusz Konieczny (talk) 09:46, 20 May 2022 (UTC)

Some of the other lifecycle prefixes use a slightly different article title pattern, such as Key:not:. I haven’t added support for that yet, but that would be one way to distinguish between namespaces and unrelated keys. More broadly, there’s only so much a simple description can do to accommodate Homonymous keys. – Minh Nguyễn ^💬 06:36, 21 May 2022 (UTC)

"Along the way, I also replaced the existing {{Taginfo}} box with a full infobox" - this seems a mistake to me, for start it is collapsed by default. And anyway, if it is useful to create data item for something it is also useful to create a wiki page for it anyway Mateusz Konieczny (talk) 09:47, 20 May 2022 (UTC)

The infobox is collapsed when following a redlink, but it’s expanded when viewing the 404 page directly, or in search results. I would actually prefer that clicking a redlink doesn’t automatically drop you into to an editor but instead takes you to the view action, which tells you what we know about the tag with an option to start a new page. As it is, users who haven’t opted out of VisualEditor only see MediaWiki:Newarticletext in a cramped panel hanging off the toolbar – hence the collapsing. Unfortunately, MediaWiki has no configuration option to point redlinks to the view action.

This infobox doesn’t preclude creating a bone fide page with the same infobox in it. It’s just surfacing information that’s already been entered. It makes little sense to include descriptions of the parts of a key but not a description of the whole key or its usage, if available. There would be a clearer benefit if I could remember how to make a Lua module get the user’s language instead of the wiki’s default language (English).

 – Minh Nguyễn ^💬 06:36, 21 May 2022 (UTC)

Anyways, in most cases where this infobox automatically appears, most of the space is taken up by taginfo and links to helpful tools like OSM tag history. I've also removed the giant placeholder image that appeared when no image was provided by wikitext or a data item. – Minh Nguyễn ^💬 19:52, 21 May 2022 (UTC)

@Minh Nguyen: This sounds very promising from the description, but it does not seem to be working for me. Is there something I need to enable first? (Btw, having a good convention for documenting namespaces/prefixes/suffixes would be useful in any case!) --Tordanik 13:02, 27 May 2022 (UTC)

@Tordanik: I neglected to mention that only a few languages' MediaWiki:Noarticletext, MediaWiki:Newarticletext, and MediaWiki:Searchmenu-new messages have been customized so far. The messages in German were still the MediaWiki default. I've added the customizations to the German messages, so now you can go to [8] to see it in action. It's pretty straightforward to add these customizations to every language, but first we need to refactor MediaWiki:Searchmenu-new to be more maintainable. – Minh Nguyễn ^💬 02:43, 28 May 2022 (UTC)

@Minh Nguyen: Thanks, works for me now. This seems like a very useful feature and would hopefully reduce the incentive to create such pages. --Tordanik 20:32, 7 June 2022 (UTC)

@Minh Nguyen: I see that https://wiki.openstreetmap.org/w/index.php?title=Key:check_date:cycleway works nicely - but maybe it would be nice to have at least documentation link to page explaining how it works? For example https://wiki.openstreetmap.org/w/index.php?title=Key:source:cycleway is not giving such info and I am unsure how it can be convinced to work. Mateusz Konieczny (talk) 08:09, 18 July 2022 (UTC)

@Mateusz Konieczny: I fixed source:cycleway=* by omitting undocumented compound keys from the list. Module:Tag had previously greedily matched source:cycleway (Q4415), which is an exact match. (Apparently Yurikbot was also engaged in building-block stub creation. If that item had had a description, it would've appeared in the infobox instead of as the compound key description.) I also added a link to edit the data item for each item in the list, which makes this generated content a little less opaque. – Minh Nguyễn ^💬 17:46, 18 July 2022 (UTC)

@Minh Nguyen: Thanks! Do you know is there any good way to detect whether page displays compound page info (such as https://wiki.openstreetmap.org/wiki/Key:name:zxx ) or standard 404 error page? Standard method of using requests in python will fail as it appears to be JS based... Mateusz Konieczny (talk) 10:59, 20 July 2022 (UTC)

@Mateusz Konieczny: The changes I made only affect the not-found message, but the server returns the same HTTP 404 response as before. The compound page stuff is static content. Nothing is JavaScript-based, other than the show/hide toggle. (This is a standard MediaWiki feature that relies on CSS to hide an HTML element initially then use JavaScript to show it on page load.) If you want to scrape the 404 page for this content, I'd suggest instead splitting the page title yourself and requesting the description for each key part using MediaWiki's Wikibase API. – Minh Nguyễn ^💬 01:40, 21 July 2022 (UTC)

I will try to test it again, it almost certainly was caused by missing display for logged out users Mateusz Konieczny (talk) 08:30, 21 July 2022 (UTC)

Enhanced not-found messages for logged out users

Resolved: Mateusz Konieczny (talk) 15:19, 22 July 2022 (UTC)

@Minh Nguyen: can it be enabled also for logged out users? Mateusz Konieczny (talk) 11:12, 20 July 2022 (UTC)

@Mateusz Konieczny: Yes, fixed for logged-out and blocked users. – Minh Nguyễn ^💬 01:50, 21 July 2022 (UTC)

Thanks! Mateusz Konieczny (talk) 08:30, 21 July 2022 (UTC)

Enhanced not-found messages for non-English users

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

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

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

Marking incomplete compound pages

@Minh Nguyen: Would it be possible to add some kind of marker like "this part of compound key is not documented" to allow automatic detection of cases like https://wiki.openstreetmap.org/w/index.php?title=Key:maxspeed:type:advisory where part of key is not actually described? This would be useful as I have long list of keys where I want to ensure that all are documented. Compound page listing is also acceptable, I guess, but I want to ensure that only fully defined compound pages will be accepted. Even specially named class or HTML comment would be better. Ideally linking to some page documenting how to document a missing segment would be present Mateusz Konieczny (talk) 14:03, 23 July 2022 (UTC)

@Mateusz Konieczny: If you make a call to the MediaWiki API for the description of each subset of key parts, then any key part that doesn't have a corresponding data item (likely because it isn't a top-level key) comes back with missing set to the empty string, while any undocumented key part has no item in the descriptions object corresponding to the language you requested. (To me, JSON is the easiest output format to work with, but you can also choose PHP, XML, or HTML output.)

If you must scrape the 404 page, there's a small edit button next to every key part that has a corresponding data item, whether documented or undocumented, but a key part that has no data item lacks the edit button. In most cases, this indicates that the key part is specific to the top-level key and can't stand on its own. Historically, we've created such pages for some very common prefixes/infixes/suffixes, but only as redirects to non-key pages; there hasn't been a general push to create pages for parts like the "pronunciation" in name:pronunciation=* or the "saltire" in crossing:saltire=*, so there wouldn't be data items either.

The lifecycle prefixes are a rare exception in that there are standard key pages with a title ending in a colon. Push-f's proposal would formalize this practice and distinguish between prefixes and keys in data items, a long-overdue improvement. Upon the proposal's approval, it'll be pretty trivial to make Module:Tag look for data items based on the new naming convention. Until then, I don't think it makes much sense to encourage creating items for non-independent key parts.

 – Minh Nguyễn ^💬 05:42, 24 July 2022 (UTC)

"but a key part that has no data item lacks the edit button. In most cases, this indicates that the key part is specific to the top-level key and can't stand on its own." - yes, in most cases: but for example in name tags it is automatically generated from some other source. Though maybe name tags are single unique case here? Mateusz Konieczny (talk) 06:13, 24 July 2022 (UTC)

@Mateusz Konieczny: Yes, name:*=* is unique because I added a special case for it to Module:Tag. As a result, name:enm=* says it's for Middle English. Even though nothing in OpenStreetMap or OpenHistoricalMap has ever been tagged with a Middle English name, the key couldn't possibly have another meaning (else it would be mentioned on Counterintuitive keys and values#Ignored existing conflicting tagging scheme). In case it helps, I linked the last-resort language name to the Wikipedia article about the language, so you could use that to detect the fallback. – Minh Nguyễn ^💬 07:23, 24 July 2022 (UTC)

data items about compound keys

What should be done with data items about compound keys such as https://wiki.openstreetmap.org/wiki/Item:Q1574 ? Is there any reason for avoiding creation of Key:name:sr Key:name:hy Key:name:as as a separate page (rather just a redirect) that would not apply to Q1574 existence?

Personally, I would support creation of wiki pages about keys for such compound tags if anything useful can be added to page over automatically generated compound tag screen, like for example illustration or some usage hints or listing related tags.

Some people above expressed desire to avoid or maybe even delete such pages. Are you applying it also to data items? If no - then why? Mateusz Konieczny (talk) 08:37, 21 July 2022 (UTC)

If there's anything distinctive to remark about these keys, such as illustrations or usage hints that are unique to these languages, by all means create the pages. I don't think it would be possible for us to display a data item–powered infobox on a redirect page. (By the way, name:sr (Q1574) has descriptions in six languages, which all appear in places like iD's help panel. If you're interested in creating a page in each of these languages containing that supplemental information, all the better.) – Minh Nguyễn ^💬 07:22, 22 July 2022 (UTC)

@Minh Nguyen: I was thinking about page like https://wiki.openstreetmap.org/wiki/Key:name:uk - links ISO 639-1 listing, mentions when it is useful, maybe have a photo depicting a sign in such language. Also, this description would appear in places like taginfo listing and category pages and would get linked in OSM Website tag listings. And has more usable presentation for regular humans than data item Mateusz Konieczny (talk) 15:18, 22 July 2022 (UTC)

@Mateusz Konieczny: There must be better examples of name:*=* pages than Key:name:uk; there's nothing specific to Ukrainian on it other than a nonessential image. Pl:Key:name:id, Key:name:lo, and Key:name:nv show basically the same information. However, the not-found page is essentially a last resort, not intended to be particularly discoverable. By contrast, the data items' contents are intended to be exposed through other mediums, such as iD.

It seems to me that the primary objection to the stub wiki pages is a maintainability cost, which is higher than for data items. Maybe that's why we haven't heard any calls to delete the compound-key data items, which were created solely based on usage statistics. As an alternative to creating a separate page for each language subkey in each language, we could put together a single dedicated wiki page with a table describing all these subkeys. That would be more maintainable, but it isn't a general solution for all "building-block" syntaxes.

Taginfo would be more user-facing and discoverable than either the data item viewer or the not-found page, but its maintainer declined to use data items as a source. [9] The reason given was that data items hadn't seen significant adoption, which struck me as circular reasoning (not to mention factually inaccurate). I'm left with the impression that there's an overriding desire for these descriptions to be embedded in wikitext – perhaps partly for backwards compatibility with familiar tools?

 – Minh Nguyễn ^💬 22:29, 22 July 2022 (UTC)

@Minh Nguyen: "primary objection to the stub wiki pages is a maintainability cost" - which exactly maintainability cost is present for pages with small amount of info? "Pl:Key:name:id, Key:name:lo, and Key:name:nv show basically the same information" - I agree, to the point of considering some template or proposing to put that repeated info on compound page listing page. "perhaps partly for backwards compatibility with familiar tools" - yes, and in my case also because (for better or worse) I deeply dislike data items while still wanting to have this somehow documented. Mateusz Konieczny (talk) 08:08, 23 July 2022 (UTC)

@Mateusz Konieczny: It would be great if folks who raised this topic originally could elaborate on what they see as the downside of the manually maintained wiki pages. It sounded to me like a concern about maintainability: a standard wiki page requires more scaffolding than a single table row or a data item. A full-page template could be helpful for keeping things in sync and reducing the effort required to treat every language equally. However, taginfo uses a homegrown wikitext parser that apparently can't expand templates, so any template that generates content would break taginfo. The generated compound key descriptions fall back to the language names in MediaWiki's copy of CLDR, equivalent to this magic word for wikitext, but even that is too magical for taginfo. Bespoke parsing of raw wikitext poses quite a severe constraint, an artificial one considering the existence of alternatives like static Wikibase dumps or Parsoid. I'm reminded of the difficulties we had with the OSMBC calendar parser before OSMCal came along and rescued us. – Minh Nguyễn ^💬 09:34, 23 July 2022 (UTC)

@Tordanik: @501ghost: @Diacritic: is there any argument for avoiding creation of Wiki pages in case where this tag has nonempty data items? What is the maintainability cost here? What would you consider as minimal threshold to create wiki page and do you think that threshold for data item should be lower? If yes - then why? Personally, I think that OSM Wiki page can and should be created where it allows adding any content at all which is not listed at automatically generated compound key listing. And that in cases where creation of OSM Wiki page makes no sense, then the same goes for data item (and if OSM Wiki page cannot be created then data item should be deleted - and in inverse, if there is data item ineligible for deletion it means that matching OSM Wiki page is waiting for creation, data items also should be treated as replaceable by compound page listings) Mateusz Konieczny (talk) 06:26, 24 July 2022 (UTC)

By the way, the bar for creating a data item is already lower in some respects: name:th (Q1577) is an example of a data item that exists even though name:th=* is a redirect. This is an intentional part of the data item data model, because editors and data consumers shouldn't have to parse and understand the freeform body of a wiki page to know what the key is about. – Minh Nguyễn ^💬 07:10, 24 July 2022 (UTC)

"editors and data consumers shouldn't have to parse and understand the freeform body of a wiki page to know what the key is about" - to get info stored in data items from OSM wiki it is enough to parse infobox, there is no need to use freeform text (and actually, when I was writing code getting it from infobox turned out to be easier than getting it from data item, at least in Python where library with parser of wikicode exists) Mateusz Konieczny (talk) 08:42, 24 July 2022 (UTC)

name:mos

@Minh Nguyen: - I found new family of what seems like valid tags without compound page descriptions. These are name:lang pages using 639-2 code where 639-1 was not assigned. See say https://wiki.openstreetmap.org/wiki/Key:name:mos

And from what I see in code name language tags fetch language info from somewhere even more magical than data items

Is it fixable? Or maybe this tag is invalid?

Mateusz Konieczny (talk) 10:37, 23 July 2022 (UTC)

@Mateusz Konieczny: name:mos (Q12043) exists and has a description, so the infobox displays that description and no compound key list is generated. It's the same result as for name:nv=*. name:mos=* is a valid tag for Mooré and is currently being used for that language. On the other hand, as of writing, name:xh (Q20578) has no description in any language yet, so Key:name:xh breaks it down into name=* and *:xh=*, which is described as "Xhosa" based on MediaWiki's built-in copy of CLDR. – Minh Nguyễn ^💬 05:00, 24 July 2022 (UTC)

Would it be possible to generate compound listing also in cases where data item is matching and this description is shown? https://wiki.openstreetmap.org/wiki/Key:name:xh at least in theory allows to reach real documentation page as it is clearly linked (and there is a decent explanation there, even if reaching it is too tricky for typical newbie) while https://wiki.openstreetmap.org/wiki/Key:name:mos as it stands does not really describe what is going on and does not allow to reach actual documentation page. Personally I would just create OSM Wiki pages for any tags which have nonepty data items, but as I understand this compound listing is intended to reduce need for this. @Minh Nguyen: Mateusz Konieczny (talk) 06:07, 24 July 2022 (UTC)

@Mateusz Konieczny: I guess it is confusing that the key is described inside the infobox sometimes but outside of it other times. Module:DescriptionFromDataItem could fill in the Description with that compound key list from Module:Tag whenever there isn't an exact matching data item description. At least it would be consistent.

Better yet, if we feel confident about the key parsing in Module:Tag, the infobox could always show the key part links (maybe even the descriptions) on every page, not just 404s. As a half measure, every name:*=* data item should technically have name=* set as its combination (P46) (example). I don't have a bot account set up yet, but maybe one of the wiki bots could make quick work of it. (QuickStatements looks kind of attractive as an alternative to bot-writing.)

There's already an edit button (a little pencil icon) at the end of the description, but maybe the infobox should have a more general link to the data item, replacing the links to edit and discuss Template:KeyDescription.

 – Minh Nguyễn ^💬 07:04, 24 July 2022 (UTC)

I would put it only on 404s, this way cases where it is wrong can be overriden rather than having mysterious source of bogus info. Mateusz Konieczny (talk) 08:37, 24 July 2022 (UTC)

But this compound info should be on all 404s about compound info, not only ones without data item: actually this listing is way more useful than infobox listing as it provides direct links to real documentation pages. Also, it is the first convincing use case of data items for me that I have seen in action :) Mateusz Konieczny (talk) 08:39, 24 July 2022 (UTC)

Updating the wiki's license

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

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

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

I support this change, I think our goal is not to create trouble for those who use the texts and images on the wiki, if they credit us properly. — Koreller (talk) 12:15, 22 May 2022 (UTC)

Support also from me. Thanks for addressing this! --Chris2map (talk) 20:36, 22 May 2022 (UTC)

Can we change OSM Wiki license without getting permission from all users who ever edited pages? (or deleting their contributions) Mateusz Konieczny (talk) 07:24, 23 May 2022 (UTC)

Yes I think that we have a legal issue, could OSM foundation help us to answer this question? (The question could also be: how did Wikipedia change its license?) — Koreller (talk) 15:58, 24 May 2022 (UTC)

GFDL license was modified to allow this - see https://en.wikipedia.org/wiki/GNU_Free_Documentation_License#Compatibility_with_Creative_Commons_licensing_terms Such action is extremely unlikely to be available to us. Mateusz Konieczny (talk) 16:46, 24 May 2022 (UTC)

@Mateusz Konieczny: That was the process for migrating Wikipedia's text from GFDL to CC BY-SA 3.0, which is far more complicated than upgrading from one version of a license to another. At the time of that migration, the Wikimedia Foundation made it a requirement to accept terms of use, which has two seemingly relevant provisions: agreeing that reusers may comply with the ShareAlike requirement by licensing their own work under "CC BY-SA 3.0 or later", and agreeing that "a hyperlink or URL is sufficient attribution under the Creative Commons license". These provisions apply only to text contributions, whereas image contributions can be uploaded under a variety of licenses. It seems that Wikimedia Commons image contributions are a vector for this kind of attack. – Minh Nguyễn ^💬 08:26, 25 May 2022 (UTC)

You can contact LWG and I expect that answer will be "it is impossible". But we can migrate/exchange media files. If someone is interested they can try to help with this part Mateusz Konieczny (talk) 16:48, 24 May 2022 (UTC)

Because CC licenses have upgrade clauses, it seems quite possible to switch to 4.0 and would not require permission from existing users. --Tordanik 15:10, 25 May 2022 (UTC)

Oh right, I was unaware of this - "You may distribute, publicly display, publicly perform, or publicly digitally perform a Derivative Work only under the terms of this License, a later version of this License with the same License Elements as this License" Mateusz Konieczny (talk) 07:05, 26 May 2022 (UTC)

See https://creativecommons.org/compatiblelicenses/ - for CC-BY-SA 2.0 they state: "Your contributions to adaptations of BY-SA 2.0 or 2.5 materials may only be licensed under: * The license used for the original work, or a later version of that BY-SA license. * Ported versions of that BY-SA license, the same or later version as the licensed work." - So later versions like CC-BY-SA 4.0 should be fine, shouldn't they? --Chris2map (talk) 11:18, 26 May 2022 (UTC)

Updating license of media files

See also proposal to ban uploading new images on such outdated licenses which is much easier to implement, also images are higher risk. See also this section with more actionable copyright actions about mislicensed images and see this section with blatant copyright issues affecting OSM Wiki Mateusz Konieczny (talk) 07:29, 23 May 2022 (UTC)

@Koreller: @C933103: @Chris2map: - note that it is much easier to achieve with images where individual files can be relicensed one by one - would you be interested in writing a text that can be send to all such uploaders? There should be some mention that it is not applicable to old works based on OSM data? If such text would exist I could use bit edit to send it to uploaders of CC-BY-SA-2.0 licensed work which is not marked as OSM-based Mateusz Konieczny (talk) 12:47, 25 May 2022 (UTC)

Polymorphic image

What is going on with File:Bench press.jpg? When displayed as thumb it displays different image than actual file Mateusz Konieczny (talk) 15:26, 25 May 2022 (UTC)

I'm not able to reproduce that. For now thumb and big one look identical to me. --Chris2map (talk) 19:25, 25 May 2022 (UTC)

I can confirm that. The thumbnail is the one of the file from Wikimedia Commons and the link leads to the local file. --Tigerfell  (Let's talk) 06:56, 26 May 2022 (UTC)

Ah ok, on Commons same filename with another picture. Since this image is new on OSM, maybe in its first minutes of existing, there was no preview / thumb image file on server or cache and system looked further on Commons and grabbed one there? --Chris2map (talk) 06:59, 28 May 2022 (UTC)

I found one more. Should I open issue at https://github.com/openstreetmap/operations ? Or is there a better place for that? Mateusz Konieczny (talk) 10:05, 18 June 2022 (UTC)

I cannot confirm your new issue. Maybe it's a cache issue? --Chris2map (talk) 10:46, 18 June 2022 (UTC)

Template documentation structure

Hello, I would like to propose you to standardize the documentation of the template of the wiki, indeed the current structure does not give me enough information about the rendering and the use of the templates.

Currently the code when creating a template is this (Template:Documentation/preload):

{{Documentation subpage}}
<!-- PLEASE ADD CATEGORIES AT THE BOTTOM OF THIS PAGE -->

=== Usage ===

=== See also ===

<includeonly>
<!-- CATEGORIES HERE, THANKS -->

</includeonly>

I would like to propose a structure that makes it easier to understand the description, use and rendering of templates, with new sections : Syntax, Parameters and Examples (and sub section Notes)

So I propose the following structure :

<noinclude>{{Languages|Template:/doc}}</noinclude>
{{Documentation subpage}}
<!-- PLEASE ADD CATEGORIES AT THE BOTTOM OF THIS PAGE -->
__NOTOC__
== Usage ==

=== Notes ===

== Syntax ==
<code><nowiki></nowiki></code>

== Parameters ==

== Examples ==
* <code><nowiki></nowiki></code> rendered :

== See also ==
* {{t|}}

<includeonly>
<!-- CATEGORIES HERE, THANKS -->

</includeonly>

See for exemple this template : Template:Bing image

Thank in advance you for your opinions and feedback! — Koreller (talk) 20:37, 2 June 2022 (UTC)

@Koreller: seems fine to me Mateusz Konieczny (talk) 11:04, 5 June 2022 (UTC)

OK to me. One question:

If <templatedata> is used, should it be put in section "Parameters"? -- Chris2map (talk) 12:29, 5 June 2022 (UTC)

@Chris2map Yes of course !

If you want more detail about my structure I already documented it in Wikisource FR.

See Template Documentation Wikisource FR, it's in french but can easily translate it in google translate — Koreller (talk) 17:34, 5 June 2022 (UTC)

Uploading CC-BY files should require stating authorship

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

Though from what I see there seems to template present that has space for that info Mateusz Konieczny (talk) 15:23, 5 June 2022 (UTC)

On side of the license templates we could add a notice for uploader to add attribution, see test on User:Chris2map/Sandbox&oldid=2336777. Notice only shows up for logged-in users (as uploaders are). --Chris2map (talk) 16:48, 5 June 2022 (UTC)

Is there any possibility in the code of the Special:Upload page to insert the CC licenses in the Information template? Then we could fill the attribution automatically with the content provided with "Author" in the Information. I made a test version to the template Information on Template:Sandbox (Template:Sandbox&oldid=2339353) that could be do like this example (User:Chris2map/Sandbox&oldid=2339354). --Chris2map (talk) 18:40, 9 June 2022 (UTC)

Unfortunately, this does not work with the upload page. --Tigerfell  (Let's talk) 13:08, 11 June 2022 (UTC)

How about an abuse filter that would catch files with missing or incomplete licenses? --Tigerfell  (Let's talk) 13:08, 11 June 2022 (UTC)

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

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

Why not Commons for OSM editors?

"Screenshots of editors like iD (ISC License), JOSM (GNU GPL v2), StreetComplete (GNU GPL v3) or Vespucci (Apache license 2.0)" are listed in Special:Upload as things that should not be uploaded to Wikimedia Commons. Why? Only when "Media files showing Bing aerial imagery, copyrighted software or web services that use OpenStreetMap data." applies it would make sense, but it is covered by another point Mateusz Konieczny (talk) 15:26, 5 June 2022 (UTC)

Well, that is not what it says. It just states that such content should be uploaded to the wiki. It means that is is legitimate to upload such content here. Afterwards, this is contrasted to content that you should not upload here. I guess that this refers to the fact that the screenshots are more relevant to OSM than to WM Commons. --Tigerfell  (Let's talk) 10:43, 6 June 2022 (UTC)

But it is still fine to upload them to Commons, I think that it should not be discouraged Mateusz Konieczny (talk) 10:03, 8 June 2022 (UTC)

Re: Licencing, they're fine, however, some of the screenshots may not be in scope of Commons, like specific JOSM functions. Berrely ^(T•C) 14:49, 12 June 2022 (UTC)

All such images are within scope of Commons, their "educational use" is broad and includes things like "detailed book how to use JOSM". Every single image usable on article pages of OSM Wiki would be in scope of Commons. Mateusz Konieczny (talk) 21:01, 12 June 2022 (UTC)

Does not involve collective use

Can we keep https://wiki.openstreetmap.org/wiki/File:Woman_holding_Ghana_flag_pendant.jpg ?

https://www.freepikcompany.com/legal#nav-freepik-license starts from "Does not involve collective use" what seems to ban use on any wiki, but maybe it is some legal term which does not actually ban it?

@Sammyhawkrad: - to let you know

Mateusz Konieczny (talk) 18:19, 16 June 2022 (UTC)

I marked https://wiki.openstreetmap.org/wiki/File:Woman_holding_Ghana_flag_pendant.jpg for deletion Mateusz Konieczny (talk) 21:12, 22 June 2022 (UTC)

Container categories category

Does category:Container categories, which is populated by {{Container category}}, need to be split by language? In fact, is it useful at all? Andrew (talk) 19:46, 21 June 2022 (UTC)

"In fact, is it useful at all?" can be used to validate whether this categories contain only categories without far more bothersome "what links here" and extra parsing. Mateusz Konieczny (talk) 21:11, 22 June 2022 (UTC)

The current state is ok for me. I think they should not be split by language. maro21 23:56, 25 June 2022 (UTC)

Trailing : in page titles for key prefixes

Some pages have them (Key:abandoned:, Key:demolished:, Key:disused:, Key:emergency:, Key:no:, Key:removed:, Key:was:) while other pages don't (e.g. Key:addr, Key:contact and Key:drink).

I think we should move the latter (leaving redirects behind) because the trailing : in the title adds clarity by indicating that the page is about a prefix (as opposed to a specific key).

--Push-f (talk) 08:22, 26 June 2022 (UTC)

+1 I support that! By the way it would be nice if taginfo link and on taginfo itself would show the total usage of a prefix key, see taginfo/taginfo/issues/355 ^GitHub. --Chris2map (talk) 09:21, 26 June 2022 (UTC)

I would certainly support reserving page names without a trailing : for keys rather than prefixes.If the Taginfo count shows a significant number of uses of the unsuffixed key create a new data item instead of changing the old one. Andrew (talk) 10:22, 26 June 2022 (UTC)

This is a more complex problem. Some of these are keys, some are prefixes, and some can be both keys and prefixes. The titles of Key:addr, Key:contact and Key:drink are undoubtedly wrong (unless we define the key differently). This calls for a larger discussion of how to treat prefixes, what a prefix or suffix is, and what a page title should be. I'll write a separate post about that soon. maro21 11:06, 26 June 2022 (UTC)

Ok, then I think, let's keep our feet still for a while. But I wouldn't make it too complicated. Unless we want to introduce a whole new wiki namespace (something like PrefixKey:), then the only way to distinguish a prefix from a regular key is to put the : after it, IMO. --Chris2map (talk) 11:25, 26 June 2022 (UTC)

Yes, I think that Prefix: namespace would be the best solution Mateusz Konieczny (talk) 11:39, 26 June 2022 (UTC)

I agree that a dedicated namespace would be nice because that would also work for key suffixes like :conditional and :lanes (and I think we can all agree that Key::conditional would be confusing). So we could have e.g. KeyPrefix:addr and KeySuffix:conditional.

On a related note, I think we should also introduce dedicated templates (e.g. Template:KeyPrefixDescription & Template:KeySuffixDescription) instead of using Template:KeyDescription for both prefixes and suffixes (because many of the KeyDescription parameters don't apply prefixes/suffixes and then the template could also take care of linking a taginfo search like https://taginfo.openstreetmap.org/search?q=demolished: and add respective categories (currently we just have Category:Namespaces, I think it would make sense to differentiate and have Category:Key prefixes & Category:Key suffixes).

--Push-f (talk) 17:08, 26 June 2022 (UTC)

Let's continue this discussion in #Tag:, Key: and... Prefix:?. --Push-f (talk) 09:17, 27 June 2022 (UTC)

File upload in page editors lacks information of copyright or license

Stuck: --Tigerfell  (Let's talk) 11:07, 17 July 2022 (UTC)

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

Thanks for pointing this out. I do not know how to solve this problem because Visual Editor is configured identically in all OSMF-hosted wikis. I would need to specify the licence template in the configuration. Those templates do not necessarily exist in the other wikis. So, fixing the issue in this wiki might break the functionality for another one. --Tigerfell  (Let's talk) 11:07, 17 July 2022 (UTC)

Hmm, do you know the place where this issue could be noted or addressed? Maybe it's possible to set a neutral named template that is only executed if existing in a wiki (and each wiki could put custom content in the template or not use it). Or maybe it's possible to have a parameter or variable that can be set in the wiki. - If this can't be implemented in short term, is there a way to sabotage the upload function in this wiki so it won't complete successfully and users have to use special:upload page? --Chris2map (talk) 19:29, 22 July 2022 (UTC)

Tag:, Key: and... Prefix:?

The discussion started here, please read it first.

I think we need a new "namespace" for keys which are not exactly keys, but prefixes. Examples:

• disused:
• abandoned:
• construction:
• proposed:

We need this distinction because the ones listed above can function either as keys or as prefixes. E.g. Key:construction (example: construction=residential) and Prefix:construction (example: construction:amenity=parking).

So for example Key:addr would be moved to Prefix:addr and Key:addr should be marked as a tagging mistake (addr=something is not used).

I think we need another template, similar to {{KeyDescription}} and {{ValueDescription}}, for prefixes and rename the page titles.
Things to discuss:

1. We need a separate template ({{PrefixDescription}}?) without as many rows as in {{KeyDescription}} - without parameters osmcarto-rendering, onNode, onWay, onArea, onRelation, requires, implies, status and without tools: Taginfo, Overpass, OSM Tag History
2. How to name prefix pages: Prefix:addr:, Prefix:disused: or Prefix:addr, Prefix:disused?
3. Should prefixes have data items? If so, we need to adjust them.
4. We should think about suffixes as well - should we call them suffixes or prefixes and create separate templates for them too? Because sometimes there are also infixes... (Let's focus only on suffixes that don't function as separate keys.)

We need to define what a prefix is, because some keys can be prefixes, but not every prefix can be key. Examples:

• name=*, source=* → source:name=*
• addr is only a prefix, won't be a key.
• disused can be a key or a prefix but they have different meanings.
• takeaway=* is unlikely to be a prefix. maro21 18:25, 26 June 2022 (UTC)

<editable list>

Words that can only be used as prefixes:

• addr, contact, drink

Words that can only be used as suffixes/infixes:

• conditional

Help finding all of them, feel free to edit.

</editable list>

It's not true that these words can "only be used" as prefixes/suffixes. E.g. taginfo:keys/addr, taginfo:keys/contact, taginfo:keys/drink, taginfo:keys/conditional. It's just that such usage does not match the documented tagging convention. --Push-f (talk) 09:10, 27 June 2022 (UTC)

These are misuses. maro21 20:39, 28 June 2022 (UTC)

I agree that we should introduce new namespaces for key prefixes and suffixes. I'd prefer them to be named KeyPrefix & KeySuffix because values can also have prefixes/suffixes.

Likewise I think the new templates should be called {{KeyPrefixDescription}} & {{KeyValueDescription}}.

I don't think we need anything dedicated for infixes because I think we can just regard them as suffixes (i.e. it might be possible to use multiple suffixes).

In case a string can be both a key and a suffix (e.g. lanes) I think we should have both Key:lanes and KeySuffix:lanes (even if the former is just a short page that links the latter).

--Push-f (talk) 18:37, 26 June 2022 (UTC)

I meant only key prefixes. Which values can have prefixes? maro21 20:39, 28 June 2022 (UTC)

I prefer "PrefixDescription". I don't understand what KeyValueDescription is, could you explain? maro21 20:39, 28 June 2022 (UTC)

Maybe I shouldn't have added suffixes to this discussion... Suffixes such as "lanes" have the same meaning as the keys they consist of (as does "source:name", which I mentioned above), so let's just focus on suffixes that don't function as separate keys. maro21 20:39, 28 June 2022 (UTC)

Maybe Key_part:lanes Key_part:addr to handle both? Mateusz Konieczny (talk) 21:30, 26 June 2022 (UTC)

I'd prefer KeySuffix:lanes and KeyPrefix:addr because they are more descriptive. I also don't think that we can rule out that a string will be used as both a prefix and a suffix at some point in the future. --Push-f (talk) 09:10, 27 June 2022 (UTC)

We would also need KeyInfix:bus for cases like Key:turn:bus:lanes with such splitting. Not sure is descriptivity worth it. Is there some sane word for that? Fragment:lanes? Mateusz Konieczny (talk) 11:50, 27 June 2022 (UTC)

"bus" is not just an infix it's also a suffix e.g. in Key:oneway:bus, so I think it makes sense to document it as KeySuffix:bus.

As per Conditional restrictions#Tagging multiple suffixes may be used together (in the documented order).

--Push-f (talk) 15:14, 27 June 2022 (UTC)

Ok it probably doesn't make sense to create 50 KeySuffix: pages for all the transport modes (establishing a category seems like a more sound way of categorizing these).

Since this is quite a large change to the wiki and there are different aspects that have to be discussed,

I have created a proposal for this change: Proposed features/Namespaces for key prefixes & suffixes (let us continue this discussion organized by topic on the talk page there). --Push-f (talk) 07:38, 28 June 2022 (UTC)

Introducing Category:Transport modes

Resolved: I no longer think that the transport mode restrictions should be added to that category. --Push-f (talk) 09:21, 19 July 2022 (UTC)

Transport modes may be used in specific positions within keys e.g.

• $transportMode=<access value>
• maxspeed:$transportMode=...
• oneway:$transportMode=...
• <transportation mode> in Conditional restrictions#Tagging

Currently transport modes (listed under Key:access#Transport mode restrictions) like foot=*, bicycle=* and motorcar=* use {{KeyDescription}} with group=restrictions (which puts the pages in Category:Restrictions).

However that category is also used for keys such as maxspeed=*, maxwidth=* and maxweight=*.

I therefore propose that we change the group to group=transport modes for pages such as foot=*, bicycle=* and motorcar=* (putting these pages in the Category:Transport modes, which I just created as a subcategory of Category:Restrictions).

(Note that not all pages listed under Key:access#Transport mode restrictions are transport modes e.g. dog=* is not a transport mode.)

Do you agree with this change?

--Push-f (talk) 06:45, 28 June 2022 (UTC)

I think "Restrictions" fits better. Because I wouldn't call "foot" a mode of transport. maro21 20:21, 28 June 2022 (UTC)

Walking is a human-powered mode of transport, see w:Mode of transport#Human powered. And just like you can get somewhere by car, by bike or by plane, you can get somewhere by foot.

It's worth noting that transport modes already are a concept present in the tagging schemes, it's therefore important that we document it properly. --Push-f (talk) 08:58, 29 June 2022 (UTC)

Walking is a mode of transport Mateusz Konieczny (talk) 10:13, 2 July 2022 (UTC)

Ok, rethinking this I don't think there is much to be gained from introducing such a category. Marking this as resolved. --Push-f (talk) 09:21, 19 July 2022 (UTC)

Improving the Beginners' guide

Please join the discussion at Talk:Beginners' guide#Messy navigation and structure. --Push-f (talk) 15:05, 11 July 2022 (UTC)

Meta proposals

Resolved: Category:Meta proposals has been created and was added to several proposals.

While most proposals are about tagging conventions and either introduce or deprecate tags, some proposals are:

• about wiki extensions e.g. Proposed features/Add Translate extension to Wiki
• about the proposal process e.g.
  • Proposed features/change vote counting rules
  • Proposed features/change vote counting rules - remove dead rule
  • Proposed features/change vote counting rules - remove no show paradox
  • Proposed features/Limit proposal discussion to Wiki
• about a template e.g.
  • Proposed features/remove link to Wikidata from infoboxes
  • Proposed features/ban deprecated tags
• about namespaces/templates e.g. Proposed features/Namespaces for key prefixes & suffixes

I think it would make sense to introduce a category for such proposals perhaps Category:Meta proposals, what do you think?

--Push-f (talk) 21:35, 12 July 2022 (UTC)

Proposed features/ban deprecated tags was not only meta proposal, it proposed to also change how tagging works. Overall I see no problem with such additional category Mateusz Konieczny (talk) 13:17, 17 July 2022 (UTC)

Template:KeyPrefixDescription

I just canceled my namespace proposal due to user experience concerns.

I think the motivation behind the proposal (better human- & machine-readability for key prefix/suffix documentation) can be sufficiently addressed solely by the introduction of new templates.

I just created Template:KeyPrefixDescription and deployed it on three pages for the sake of demonstration:

• Key:addr (before for comparison)
• Key:contact (before for comparison)
• Key:drink (before for comparison)

{{KeyPrefixDescription}} has the following differences to {{KeyDescription}}:

• the box title shows :* after the prefix
• the template adds a banner like the one currently used on the lifecycle Key: pages (e.g. Key:disused:).
• the template also automatically generates a link to a taginfo search (which previously were usually added manually)
• the Tools for this tag section is not displayed when using {{KeyPrefixDescription}} since these links aren't actually relevant for prefixes

What do you think about this new template?

--Push-f (talk) 09:51, 18 July 2022 (UTC)

"Should not be used as a key. " at Key:addr is highly confusing and the proposal would allow to avoid this :( Mateusz Konieczny (talk) 22:15, 18 July 2022 (UTC)

Thank you for bringing that up! I agree that this wording is very confusing. But this notice was just part of the description, so I just improved the descriptions of these three pages. Note that my proposal would not have prevented confusing descriptions, that's a separate problem. I think the notice "This tag page describes a key prefix rather than a simple key." automatically added by the template is quite clear. --Push-f (talk) 04:25, 19 July 2022 (UTC)

Note that I am not against this description in the current stage of page! Describing prefix rather than key on Key: page without making it clear is even worse Mateusz Konieczny (talk) 06:34, 19 July 2022 (UTC)

I think that the infobox added by the template makes the situation quite clear. --Push-f (talk) 08:32, 19 July 2022 (UTC)

Ok, I now see what you mean. It would be nice to have a {{KeyDescription}} for addr=* with |status=deprecated. And I agree that having two infoboxes on the same page (one about the key prefix and one about the key) would be confusing.

So I just revived my proposal: Proposed features/Documentation of key prefixes & suffixes (I'm suggesting a different page naming convention that does not have the UX concerns of namespaces). --Push-f (talk) 08:32, 19 July 2022 (UTC)

What to call prefixes like source:, note: and check_date:?

I think it would make sense to somehow distinguish prefixes that may be added to any key and change the meaning of the whole tag from regular prefixes. E.g. (source: / note: / check_date:) vs (addr:, contact:, drink:). This however requires us to come up with a name for the former ... perhaps "meta prefixes"? Cause these tend to be tags about tags. What do you think? --Push-f (talk) 04:34, 19 July 2022 (UTC)

Universal prefixes? Mateusz Konieczny (talk) 15:05, 19 July 2022 (UTC)

@Push-f: I've been calling these "qualifier prefixes" because they qualify other tags rather than the feature itself. Another option would be "meta keys". – Minh Nguyễn ^💬 05:31, 24 July 2022 (UTC)

Documenting changeset tags separately from element tags

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

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

• Changeset/Key:source
• Changeset/Key:created_by
• Changeset/Key:imagery_used
• etc.

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

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

Maybe Changeset key:created_by or ChangesetKey:created_by instead of namespace that has own baggage would be better? Mateusz Konieczny (talk) 11:20, 20 July 2022 (UTC)

Yeah that would also work. In that case I'd prefer CamelCase. A small advantage of using subpages would be that they would automatically link to Changeset but I guess such a link could also be produced via a template. --Push-f (talk) 04:57, 21 July 2022 (UTC)