Talk:Wiki/Archive 12

Redirects from prefixless forms to Key: and Tag: articles

Resolved: No changes decided upon. --Chris2map (talk) 16:23, 3 November 2025 (UTC)

Whenever I search for a combination such as foo=bar I get slightly irked by being presented with search results, rather than immediately redirected to Tag:foo=bar. We do have a few such redirects in place, such as ref→Key:ref, but those have been created haphasardly, since, for example, int_ref is currently a redlink rather than a redirect to Key:int_ref.

Having such redirects in place would also be beneficial for linking from e.g. the Community Forum to Wiki pages -- since it's commonly used, it may be even assigned a custom Markdown syntax if there's enough interest.

Now, there are thousands of pages with Key: and Tag: prefixes, and only a few redirects in place. If we decide having such redirects would be a good idea, Someone(TM) would have to develop a script or bot to create (and/or maintain) them. Duja (talk) 13:33, 28 February 2024 (UTC)

If you need such a redirect for some frequently used tag, then just create it. I do that sometimes. I usually start by typing in some popular word, such as restaurant or restauracja. If there is no such redirect, I create it. There is no objection to creating such redirects, but I don't see the point in automating this and creating them for all tags, e.g. diplomatic:services:non-immigrant_visas, which will redirect to Key:diplomatic:services:non-immigrant_visas. maro21 19:54, 28 February 2024 (UTC)

I'm not shy on editing Wiki (coming from the Wikipedia world), and I also created a few such redirects. As I said, I'm only slightly irked, but as we know, irk tends to accumulate over time, so I wish we would automate the process. I suppose that irk fades in comparison with encountering admin boundaries glued to roads glued to landuse glued to waterways, with a dose of multipolygon relations to ensure everything stays glued and can never be edited... Duja (talk) 21:06, 28 February 2024 (UTC)

Equivalent of {{Tag}}, but links to data items

Resolved: templates has been created Something B (talk) 09:16, 5 November 2025 (UTC)

Usage:

• {{TagItem|key|value}}
• {{KeyItem|key}}
• {{ValueItem|key|value}}

For example, shop=clothes. Something B (talk) 13:12, 14 March 2024 (UTC)

Thanks for the info. Documentation for the template would be useful. And maybe a different background color to distinguish these links from the regular ones. maro21 22:43, 14 March 2024 (UTC)

I also had a similar question when I wanted to add a general link to data item to the tag description boxes (Template:Data item link). Unfortunately we don't have an icon for data items, like with taginfo. Perhaps one of the following display variants can be used instead:

1. variant for link to ^#shop=clothes
2. variant for link to ^d.i.shop=clothes
3. variant for link to ^dishop=clothes
4. variant for link to ^‹›shop=clothes
5. variant for link to ^■shop=clothes
6. variant for link to shop=clothes
7. variant for link to ^d.i.shop=clothes

--Chris2map (talk) 11:57, 17 March 2024 (UTC)

There are some emojis that can be used as icons for data items. Here are several I selected from this query on emoji DB:

1. 📊
2. 📋
3. 📝
4. 🧾
5. ✉
6. 🛢

I like #2 ("Clipboard" emoji) best, e.g. 📋shop=clothes. Duja (talk) 09:02, 18 March 2024 (UTC)

Note that we already have {{O}} for linking to data items, which is quite flexible in the output formatting. In any case, even if we keep Something B's templates around, they can be reduced to a single template called e.g. {{Item}} rather than having three quite similar copies. Duja (talk) 09:39, 18 March 2024 (UTC)

This templates uses Special:ItemByTitle in comparison to {{O}} which uses item ID. {{ValueItem}} and {{TagItem}} are analogous to {{TagValue}} and {{Tag}}, respectively. {{KeyItem}} may be replaced with {{TagItem}}, if someone add branches, as in {{Tag}}. Something B (talk) 10:04, 18 March 2024 (UTC)

Syntax for relation role page names

Resolved: Property:P54 had been created. --Chris2map (talk) 16:30, 3 November 2025 (UTC)

Hi, there's been some discussion at ideditor/schema-builder#174 ^GitHub about creating a wiki page for each relation role, to make it easier for editors like iD to access the documentation for a specific relation role.

There is a question about what the syntax should be for the page names. For example:

• Relation:multipolygon/Roles/outer
• [[Relation:waterway/Roles/<blank>]]

Does anyone have suggestions or ideas? There's some more info and context in the github issue. thanks! --Kylenz 20:10, 30 December 2024 (UTC)

I don't think we need separate pages for roles. There isn't much information to create a new article. Roles should be described on relation pages. maro21 21:56, 30 December 2024 (UTC)

I agree with maro21 that roles are best described on relation pages. A few pages about roles do exist, such as Role:from or Role:outer, but they act more like disambiguation pages. However, what we should do is to improve descriptions on data items, which are displayed in iD's user interface (as tooltips?). For example, Item:Q16069 currently has empty English Description field.
As Minh mentioned on Github, all role data items are listed at Special:WhatLinksHere/Item:Q4667. Duja (talk) 09:59, 31 December 2024 (UTC)

I added descriptions for two dozen most common roles [1]. Duja (talk) 12:18, 31 December 2024 (UTC)

As long as we consider the relation article to be the source of truth regarding the roles, the relation type's item needs to indicate the associated roles somehow too. I've created relation member roles (P54) to link from the relation type item to each of the role items for that relation type. From a computer science standpoint, such an inverse property would be frowned upon, but here it's just a consequence of our content organization. This isn't quite a solution for gaining access to the role descriptions, but it gets us a little closer. – Minh Nguyễn ^💬 09:07, 5 January 2025 (UTC)

Aren't those just the inverse relations of belongs to relation type (P43), and could be obtained by querying those (not that I'm familiar with the API)? I'm fairly wary of including fully redundant information in the data model. Duja (talk) 19:06, 5 January 2025 (UTC)

@Duja: Yes, it is an inverse relationship. The basic Wikibase API offers no built-in way to query inverse relationships. Special:WhatLinksHere isn’t quite the same because it doesn’t care at all about the semantic context, just the link in the rendered output. We’ve been waiting for WikibaseCirrusSearch, but even this isn’t quite adequate; it’s more for search than for parsing deterministically. Sophox would be the prime tool for more flexible queries on this Wikibase instance, but it isn’t in a state of health that we could confidently point popular editing software to its live API. My point of reference is Wikidata, which generally frowns upon inverse properties but sometimes makes an exception for properties such as has subsidiary (P355). Compared to the bogus sitelinks, this might be the lesser of two evils. – Minh Nguyễn ^💬 05:50, 6 January 2025 (UTC)

Annnnd I just realized Data items#Relation roles documents that each role item already has a sitelink to a bogus nonexistent article such as "Relation:boundary=admin centre". So this already makes it possible to query for the role item without creating any pages. The only downside is that the documented syntax is very well-hidden and could have some unexpected side effects based on what the user enters as the role in iD. – Minh Nguyễn ^💬 09:31, 5 January 2025 (UTC)

Organizer keeps removing reference from own activity on the Organised_Editing/Activities

Resolved: at least for the discussion here. --Chris2map (talk) 17:24, 3 November 2025 (UTC)

Admins, please give a look at recent edits on https://wiki.openstreetmap.org/w/index.php?title=Organised_Editing/Activities&action=history . An individual of one of the 3 organizations involved is removing any reference of own activity from the list. I'm unsure if something similar happened in the past, but how to react to this?

(by the way: the armchair organized editing happened in my province, and I can plan a trip to survey it.) --EmericusPetro (talk) 07:29, 21 December 2023 (UTC)

I commented in https://wiki.openstreetmap.org/wiki/User_talk:Everton_Bortolini - but maybe you know, is it duplicate of documentation existing already? If yes, where it exists? Mateusz Konieczny (talk) 14:00, 21 December 2023 (UTC)

@Everton Bortolini: Mateusz Konieczny (talk) 14:01, 21 December 2023 (UTC)

I think it would make sense to have detailed problem list in 2023 Brazil Floods where there is more space for them, with only summary in Organised_Editing/Activities. Not sure should it get own entry or be noted in HOT entry (is it HOT-run edit?). From looking at scale of issues it may make sense to let know more HOT people about the problem (if you have time, interest etc to join their forum/slack/whatever) - or just let them know using info@hotosm.org provided at Organised Editing/Activities/Humanitarian OpenStreetMap Team (in either case noting whether they responded also makes sense) Mateusz Konieczny (talk) 18:28, 21 December 2023 (UTC)

@Mateusz Konieczny: I agree to move the community objections another and just leave a summary on Organised_Editing/Activities. However, the copy needs to be in a dedicated page, where it cannot be simply edited at will by the other side like what is happening right now. And the organizers lied while defending it could be deleted from the listing: on https://wiki.openstreetmap.org/w/index.php?title=Organised_Editing/Activities&oldid=2633081 the change summary of changes uses "(...) Notes were copied to the project wiki page." without faithfully copying what was written on the target page. If anyone wants an example omissions/changes, I can detail better, but it was not copied. If the activity organizers will challenge if what's written is not local community opinion, their best approach is go back to @osmrs however neither me or the others here need to "discuss with Brazilian community" and even the early contact with DWG the osmrs was the channel used by both. To explain why the telegram of OSMRS is relevant, later I will add context (sorry, will be a wall of text) from the date of disaster they appeared on @osmrs and recently moving away while deleting previous messages.). --EmericusPetro (talk)

If you need more help with cleanup and people running this organised edit are failing to clean up after it (note, I have not verified claims made by you) it may make sense to ask local community for help, and/or write at https://community.openstreetmap.org/ and/or contact DWG @EmericusPetro: @Everton Bortolini: Mateusz Konieczny (talk) 18:30, 21 December 2023 (UTC)

(Emerson here, start) I will give a context in English from 2023-09-13 to 2023-12-15, since this situation might escalate (and also to explain that "not discussed in Brazilian community" is misleading as they and DWG know it was the closer group to the region)

• the cities flooded on 2023-09-05 are on Vale do Taquari, a region in Rio Grande do Sul province, which does have likely one of the more active province-level Telegram in Brazil ( https://t.me/osmrs , or "@osmrs" ). Except by the invitation to map in the initiative (and first weeks, to ask anyone local to be an organizer) on the closest telegram group to the region (which is @osmrs), all decisions were made in closed groups by these organisations.
  • Several promises and general answers from questions were made on @osmrs  by the organisers. However, recently (around 2023-12-15?) one of them deliberately deleted a lot of own messages with these promises (including one promise to prove which mapper/validator was in the city by providing a photo, which is why, unless they prove, we here can say this activity was armchair-only mapping plus Google Street View. As an example of deletion this  https://t.me/osmrs/25899 message today goes 404 not found, but both previous (https://t.me/osmrs/25898) and next (https://t.me/osmrs/25900) are online. Depending on the Telegram client used to see the chat, may or not display if it is replying to a deleted message
• After their supposedly 100% validation step, it was me from the group who stopped to look. I started to see potential red flags (sense: blatant things which shouldn't even be there after review, and I'm NOT talking merely about non-squared buildings). The start of this was 2023-11-19 <https://t.me/osmrs/25875> and next messages with others in the osmrs group. Yet, the organizers (while very active to invite to map in preview us weeks) with the finalized event simply... didn't reply at all! One peer (@santamariense, which I do respect his work, and he is from the region) suggested we simply mass edit to building=yes could be enough, but there was other issues with fake data with needs non automated verification (plus the need to undelete things)
• Without the responsible for the Organized Editing replying to the complaint, and no one local with time to carefully review, I started to research how to do a full revert of over 2000 changesets. And with this call in public (where I had to mention all the supposedly organisers, hard to know since it was undocumented ) here 2023-11-20 <https://t.me/osmrs/25898> and saying that unless they took we would revert, this make an immediate response on , we got the initial reply of first attempt to post-validation here 2023-11-20 https://t.me/osmrs/25899 (now deleted) that they would start it review again.* 2023-11-22 DWG contacted [Ticket#2023112210000181] . At this moment, the DWG contact already knew that @osmrs (the province group) was used by both sides, however since the organizers already were attempting to review, it made sense to give more time.
• The said first post-revalidation revalidation didn't happen in practice. Every one of the mentioned issues in @osmrs telegram chat persisted. For example on 2023-11-19 https://t.me/osmrs/25889 the mentioned shop=clothes (node/4917865622) moved by an armchair mapper (note that even addr:street still use old street)still even today in the live server (this shop=clothes was the initial example of red flag of what could happens even with their review). However, to be fair, one of the global validators (very friendly) which I had open discussion with in changesets actually fixed manually some (not all) the new building= different than yes, but other than him, it's unclear if they don't know how to fix it. Trust me when I say that this is not a typical problem of unsquared buildings any of you would see like in rural Africa, but affects PoIs (and there's people like me to survey if necessary and find these brown MM's)
• Not only because it was slow to fix it, but unclear if they would do it right, I asked on telegram again 2023-11-27 <https://t.me/osmrs/25926> andthen 2023-12-11 <https://t.me/osmrs/25969>. The reaction of the organizers was that they didn't know at all about https://osmfoundation.org/wiki/Organised_Editing_Guidelines>, from things like not really being their responsibility to fix or have to respond within 2 business days. 'This explain why (in addition to data related requests) the text contains parts about make commitments to acknowledge the OEG in any future event by any of the organisation who coordinated this one They don't want the data to be deleted, but they don't seems to like complains that they need to fix it.
• A drastic change happened 2023-12-14 when I posted on @osmrs that A) that even the documentation for the Tasking Manager advice to NOT allow beginners edit projects like this and B) year before a global validator  on the question and comments section of https://tasks.hotosm.org/projects/13594 (a 2022 a project of UmbraOSM, one of the 3 organizers) that they're releasing a complex project for beginners and also that the tagging building=residential instead of building=yes and C) that a change on the Tasking Manager this year now allow project admins to delete public messages on the "questions and comments section" and an global validator on the projects in discussion now already had warned about low quality. Immediately after, one of them proposed to move the decisions to whatever the current data (note: there is still both fictitious and even Google copyrighted data) needs reversion from the telegram of the province osmrs to the telegram of the country.
  • Note: while I did not shared on the telegram, the link for the discussion with the global validator was https://www.openstreetmap.org/changeset/143333801, it's in portuguese, but is around  "Nesse meio tempo, também entrei em contato com o organizador ou com meus colegas da HOT sobre a qualidade às vezes ruim do mapeamento."
• While from my province is me who took the time to investigate the problems (is very, very time consuming) others like Gustavo Schenkel (one of the group admins) on https://t.me/osmrs/26034 explicitly asked if they're following the Organized Editing Guidelines.
• The last reply from the organisers was 2023-12-15 https://t.me/osmrs/26037 (archive-1 archived-2 ) which, in direct translation means "I wish you all good luck! There is my email in the documentation and I will be on the national channel." (Original message in portuguese: "Desejo boa sorte para vocês! Tem o meu e-mail no documentação e vou estar no canal nacional.")
• And finally, 'in addition to previous weeks where only changeset and public chat messages about the objections on @osmrs, on 2023-12-19 https://t.me/osmrs/26045 I posted the link to Organised Editing/Activities to have a summary English with examples.
  • If any true local mapper from here ask me to review something (such as make changes on request commitments to OEG; the data problems are less subjective), I will obviously take them seriously. Until now, no objections neither in private nor in public.

(Emerson here, end) --EmericusPetro (talk) 05:57, 23 December 2023 (UTC)

" where it cannot be simply edited at will by the other side" - response is still fine I guess. Can you copy missing parts to 2023 Brazil Floods ? Mateusz Konieczny (talk) 19:38, 23 December 2023 (UTC)

@Mateusz Konieczny: Matheuz and others: if infeasible leave the full compilation on the column "Community objections?" at Organised_Editing/Activities, then make a snapshot from the deleted content of https://wiki.openstreetmap.org/w/index.php?title=User_talk:Everton_Bortolini&curid=312169&diff=2634479&oldid=2633578 at Organised_Editing/Activities/2023 Vale do Taquari Floods/Community objections with a literal copy (and link to where it was extracted, the deletion) and a prominent warning to the organizers NOT to edit the page. The "Vale do Taquari" in the page title (or, less precise but still closer region above, "Rio Grande do Sul") is very important, it is non negotiable. The reasoning is the recent shift to name this "Brazil Floods" (despite all description be from cities in the Vale do Taquari) is not merely geographically misleading, but also attempt to boycott the previous discussions with the local community @osmrs with extensive chat history (part by their side is deleted, but not all) with clear intent to allow armchair mappers from the same organizations who created the event to vote to allow anything (from copyright data to deletion of surveyed data to re-create again). If you or others decide to copy missing parts from the Organised_Editing/Activities/2023 Vale do Taquari Floods/Community objections to 2023 Brazil Floods, then anyone else can do it. --00:50, 24 December 2023 (UTC)

still not investigated it in detail but I noticed part about "it is non negotiable" - I would advise against such claims. Also, not sure has it happened but I would strongly advise against trying to hide that some problems happened, better to describe how they were resolved and will be avoided in future. Neither communication strategy is a good idea Mateusz Konieczny (talk) 13:42, 27 December 2023 (UTC)

Documenting changeset tags separately from element tags

Resolved: Dedicated templated has been created

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)

On a related note I think we should deprecate use on changesets (P37) and instead introduce data items "changeset key" and "changeset tag" to be used with "instance of". --Push-f (talk) 11:23, 1 August 2022 (UTC)

@Push-f: - are you interested in creating this templates? If yes, then feel free to do so, there was more than enough time to protest/comment and this idea makes sense (I also had this idea, not done it only due to limited time) Mateusz Konieczny (talk) 17:18, 3 November 2023 (UTC)

See also currently discussed issue Talk:Tag_status#Discardable_on_entities,_but_usable_on_changesets. I support establishing a namespace for changeset keys. Camel case ChangesetKey: would be fine! -- Chris2map (talk) 19:18, 3 November 2023 (UTC)

So how? ChangesetKey:created_by -- Something B (talk) 23:09, 3 November 2023 (UTC)

@Something B: Yes, but the "whole system" (templates and module) needs to be educated and adapted to it, I must admit. See Template_talk:ChangesetKeyDescription.

An alternative could be one of these notations for the pagenames:

1. Key:(Changeset) created_by – example
2. Key:Changeset - created_by
3. Key:-Changeset- created_by
4. Key:Changeset/created_by
5. Key:Changeset//created_by

I like no.1 too. Should be working without reworking the module. --Chris2map (talk) 13:49, 4 November 2023 (UTC)

I think that splitting the documentation into two articles isn't a good idea.

First: links from the main OSM website will still direct to Key:created_by: https://osm.org/changeset/100000000

Secondly:

• the [created_by] tag as a tag used in the main database actually only needs an infobox: with usage statistics, status, description, just like any other tag or key in the database.
• for that [created_by] as a tag used in the changeseet needs a description, but for that it doesn't need an infobox at all with information on whether it is to be used on nodes or not, because it is not used on Elements at all. Thus, I would leave it as it is. Alternatively, you could make it so that on one page there is a description of both the changeset key and the key from the main database, separated by a horizontal line, for example: [2]. maro21 21:48, 7 November 2023 (UTC)

The first point (link from an OSM changeset) is an important note but I'd say that could and should be updated. Does anyone know if OSM website uses the documentation links from the data items (like iD editor) for these tag links?

To the secondly points: I prefer to document changeset keys or tags separately from the element tags. I'm with you that changeset tag pages don't need the element tag infobox, or at least an new infobox with different layout (neither tag descripition nor feature description). So I would use ChangesetKey: and ChangesetTag: pages with new distinct layout. Or should we abstain from those separate pages and list (document) all changeset tags on one single main page?

In addition the element tag pages could get a uniform link notice to the documentation place of the changeset tag of the same name. --Chris2map (talk) 18:01, 8 November 2023 (UTC)

@Chris2map: The part of the infobox that says which element types you can use the key/value on now includes an icon indicating whether it's a valid changeset key/value, based on use on changesets (P37). With this change, pages like clacks_overhead=* can be documented as "in use" without causing as much confusion. – Minh Nguyễn ^💬 18:22, 10 November 2023 (UTC)

I have to say that it is not clear to me how the different nature of element tags and changeset tags can be recognized and how we want to provide different information for e.g. status or combinations etc. in the description box. In case of single wiki page that would then need at least an additional box for the changeset use case. IMHO, the additional icon is far from enough to make these different cases recognizable and understandable. --Chris2map (talk) 08:11, 11 November 2023 (UTC)

@Chris2map: That's true, but I would consider it just another case of homonymous keys where the usage differs by element type. Otherwise, if we relegate changeset usage to a separate page, we have to work harder to make that page discoverable than if it's in a separate section on the same page. For OpenHistoricalMap-specific tag definitions, we're relying on {{See OpenHistoricalMap}} to make the OHM page more discoverable, but for changegset keys/tags I think that would make it look like more of a special case than it is in reality. – Minh Nguyễn ^💬 22:34, 11 November 2023 (UTC)

@Minh Nguyen: I see your point with fragmented and findable documentation. To jump to the start of this discussion: Look at the very first 4 sentences. It is an important thing to clear a status of an element tag to me too. Meaning, if e.g. usage in the map (on elements) was discardable that should be provided on the tag page to users and software (like taginfo). In such a case a different status, since usage on changesets is active, wouldn't be appropriate to me. This leads to 2 statuses on one page or to no status for the changeset usage. The former is currently tested on Key:created_by but in this way it is no solution and increases confusion rather than reducing it, IMHO. Then I would prefer to leave out the status for the changeset use. --Chris2map (talk) 08:10, 12 November 2023 (UTC)

@Chris2map: I concede that there’s a tradeoff in terms of being able to definitively state the discardable status of an otherwise acceptable key for changesets. To me this is similar to the situation with type=*: deprecated on nodes and ways, but required on relations. – Minh Nguyễn ^💬 18:54, 14 November 2023 (UTC)

@Minh Nguyen: I obviously make a much bigger distinction between the two cases (changeset and entities). To be honest, when it comes to changesets, I would prefer not to even talk about the terms tags and keys. For me, these belong to map elements and map features and I therefore see a fundamental risk of confusion if it is not treated separately for changesets (not in technical way but in terms of feeling). But I definitely don't want to be petty here. The current path is already a big step forward and will result in a good tradeoff. But it would be nice if we weren't the only ones writing "ping" pong here. What do others think? --Chris2map (talk) 19:19, 14 November 2023 (UTC)

"Does anyone know if OSM website uses the documentation links from the data items (like iD editor) for these tag links?" - no, it links and check OSM Wiki pages Mateusz Konieczny (talk) 08:51, 13 November 2023 (UTC)

@Mateusz Konieczny: Actually I think it’s just hard-coded to point to the articles. [3][4] – Minh Nguyễn ^💬 18:54, 14 November 2023 (UTC)

"only needs an infobox: with usage statistics, status, description" - well, their status is different Mateusz Konieczny (talk) 08:50, 13 November 2023 (UTC)

I took the liberty of carrying out a test with a layout variant (proposal of styling) to Template:ChangesetKeyDescription (using Template:Description/sandbox). Style is derived from changeset view on www.openstreetmap.org/changeset/... – Have a look at Key:created_by and Key:imagery_used. – What's your opinion? --Chris2map (talk) 17:52, 13 November 2023 (UTC)

The parts of the infobox that come from the data item might need some extra attention, since an article can only be linked to a single data item at a time. What we can do for these cases is to qualify the status (P6) statements with one or more “applies to” qualifiers that the modules can look at. This would be useful not only to the infobox but also anything else that’s using the data items directly. If there’s support for this idea, I can create the necessary property. – Minh Nguyễn ^💬 19:06, 14 November 2023 (UTC)

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

Resolved: see below Something B (talk) 09:21, 5 November 2025 (UTC)

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

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

Commented on https://wiki.openstreetmap.org/wiki/User_talk:Bigshot#Veneto%2FLagune_e_zone_umide%2FLaguna_di_Venezia Mateusz Konieczny (talk) 10:10, 5 November 2023 (UTC)

That page used to be a working reference for the local mappers group.

I think it's a good idea to move up references to all the main page for each (not only Waterways) map feature indicated with a big warning about the importance of checking there any update about keys and values.

At the same time deleting that page would be a big error since it's a good help for local mappers: local words, non even in italian, are still widely used and this "local dictionary" is key to prevent lack of homogeneity inside the same actual part of the map. This is actually a very heavy problem in Venice with all the tourist mappers keeping a very chaotic set of different standards. Unfortunately the local mapper group didn't live long enough to complete the task.

In the meanwhile i would just mark it as not up to date as suggested by maro21 --bigshot (talk) 14:48, 8 November 2023 (UTC)

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

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

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

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

"Can we trust Commons ? Should we trust Commons ?" - I think so, they are relatively stable and well managed. Though maybe making backup of files we are using is a good idea - good project for anyone suspecting trouble. this may be a good first step Mateusz Konieczny (talk) 21:44, 25 November 2022 (UTC)

"What could we gain by moving some of our files there ? "

Free photos are more reusable and easier to find by others (better categorization, more normal location, more trustworthy in general)

Photos uploaded to Commons are immediately usable on Wikipedias and other Wikimedia projects making easier to illustrate OpenStreetMap articles across Wikipedias (or other related articles with OSM-related content)

Better review of licensing situation (for example, photos depicting modern statues in France are problematic due to FOP situation - there are some people on Commons aware of such traps and acting on it, while here for multiple years we had massive amount of clear copyright violations and noone noticed. Some were clearly labelled.). Though that is a bit of tough sell, as in other words it is "maybe your photo will be deleted due to obscure stupid laws"

Forces us to review licensing situation (again a bit tough sell, but it is worth doing)

Encourages people to upload to Commons in the first place. They have much better upload interface, ours is basically broken - see [5] [6] that results in well intentioned people uploading own photos and ending in limbo legal status anyway which is tremendous waste

Commons has some special tools like license verification bots allowing to confirm Flickr license claimed during upload

During transferring files often one finds clearly superior versions. For example this soon to be deleted local version is of much smaller resolution than full photo that I found during transferring it

Mateusz Konieczny (talk) 21:44, 25 November 2022 (UTC)

"I have personally tried to put as little as possible on OSM Wiki (especially things that are impossible to put on Commons like Maxar satellite imagery)" - and thanks for that, in case of uploading them locally it is likely that you would miss license or even worse "that is my own work" claim that would make things complicated. Also, such uploads are far more likely to be used by others (I benefited from that during StreetComplete development that people uploaded stuff to Commons rather some local wiki) Mateusz Konieczny (talk) 21:48, 25 November 2022 (UTC)

Wikimedia Commons is a separate project, and I don't see any reason to force someone or suggest moving. If a person who adds the template wants to use a file on Wikipedia or a similar project, they can always make a copy on Commons - it is not forbidden as long as the license is compatible. I think OSM-related files should be here, because in case someone wants to upload a new version, they will do it here. The {Move to commons} is a copy of a template from Wikipedia, which was created not to keep images on just one Wikipedia, but to make them available on Commons, so that other Wikipedias can use the image too. In our case, it is unnecessary. Besides, I think most of the files we upload here don't fit on Commons. maro21 20:59, 19 April 2023 (UTC)

@Maro21: "I don't see any reason to force someone or suggest moving" - main reason is that we are incapable of even reviewing images for copyright violations, osm-related images on Commons will be more widely reusable (for example on Wikipedia), we have major trouble with setting up upload interface and so on Mateusz Konieczny (talk) 12:46, 15 December 2023 (UTC)

"Besides, I think most of the files we upload here don't fit on Commons" - not really, only images which use proprietary imagery like Bing and images here on fair use (complex logos of sponsors) are out of scope of Wikimedia Commons. Mateusz Konieczny (talk) 12:46, 15 December 2023 (UTC)

Resolved: discussed, will link it from template talk page Mateusz Konieczny (talk) 20:30, 2 November 2025 (UTC)

Photo for SoTM, no evidence of a license (any)

Resolved: file deleted [7], images replaced, see also [8] --Chris2map (talk) 18:36, 12 November 2025 (UTC)

Photo from third-party, license not mentioned at all: File:Libya3.jpg. Something B (talk) 14:54, 9 November 2025 (UTC)

Uploader was recently notified in https://wiki.openstreetmap.org/wiki/User_talk:Kateregga1#License_of_images_on_State_of_the_Map_Africa_2023/Call_for_venues/Libya Mateusz Konieczny (talk) 07:17, 11 November 2025 (UTC)

Redirect pages for keys and tags

Is there anyone else who finds redirect pages for keys and tags an obstacle for the access of information? If there is no page for a key or tag, the description box is displayed nevertheless (e.g. Tag:location=platform). But if the page was created with a redirect there is no content, no description box. As a result you didn't get displayed information available from taginfo (usage) and/or the corresponding data item. On the one hand that makes it more difficult to obtain the information, on the other hand it disables accessing / maintaining data of the data item. And languages bar is also missing so you cannot find the page in other languages that may exist.
I suggest one of these two options:

1. Not to create redirects for keys and tags, but stub pages with the description box and a link to the page, that would be the redirect target, at least.
2. Place a bare description box template after the redirect to display the description box (in order to have the links to taginfo and data item and show information from data item if available). For this I created the Template:Description/nocat that reduces categorization of those redirect pages to a minimum. The page content then would be

#REDIRECT [[...]]
{{Description/nocat}}

See e.g. Key:addr:door.
The reason for a bare template is that we don't want to maintain page content on a redirect page, I guess. --Chris2map (talk) 07:34, 26 July 2025 (UTC)

See also Key:dual_carriageway that redirects in prose. I like both solutions Mateusz Konieczny (talk) 05:24, 5 October 2025 (UTC)

Resolved: seems answered Mateusz Konieczny (talk) 07:31, 11 November 2025 (UTC)

New tag and Wiki label "invented tag"

At Any tags you like it says "You can use any tags you like, but please document them here on the OpenStreetMap wiki ...". So it is recommended to document an invented tag, probably with a key or tag page. This leads to the issue that the new tag might look like an established tag or a tag with community support at least. Since I believe that an established tag should be recognized as simply and clearly as possible, or conversely, an invented tag should also be recognizable as such, I see two possibilities:
1) Change the guideline and recommandation so that a tag page is not created until the invented tag receives support through discussions.
2) Enhance / extend the guideline and recommandation that the nature of tag as new invention should be clearly expressed and how this can be achieved. – For the latter I want to propose the tag / Wiki label "invented tag". I created a template for example - {{Invented tag}} - based on the existing {{Undocumented tag}}. – What do you say about the topic and the proposal? --Chris2map (talk) 14:01, 30 August 2025 (UTC)

I am in favor of second variant. Something B (talk) 14:08, 30 August 2025 (UTC)

At first glance, I am not in favor of either of these proposed changes. Option 1 means stronger "notability" gatekeeping which is the thing that pushes many people, including me, away from Wikipedia editing. Option 2 is similarly judgmental, and either self-fulfilling or quickly becomes outdated.
For someone to go through the effort of developing a tagging schema, putting it into use, and documenting it here on the Wiki, just for the page to be deleted or red-marked as "invented" (which all tags are, so at bare minimum Option 2 would need to use a different term) is really discouraging and is the exact opposite of the direction we should be heading.
To offer an alternative that sidesteps these issues: how about incorporating automatically-added notes to the existing, widely-used TagDescription (and related) templates that, based on objective statistics from Taginfo, flags tags as low-usage (via either an absolute number of instances, an absolute number of users, or some function relating the two)? Lumikeiju (talk) 05:44, 2 September 2025 (UTC)

Thank you for your replies and thinking! I admit, I looked at the whole thing from a maintenance perspective. With the advice on avoiding hurdles or deterrent regulations, you have focused attention on a crucial topic. – I am looking for solutions / improvements that make it easier to react to issues such as: A) In discussions, it's often pointed out that there's a wiki page for the tag, so it's good to use. This means that the mere existence of a wiki page is often cited as official recognition or at least as a measure of the quality and validity of a tag. No matter of the factual usage. B) I understand that not everyone can or wants to create a formal proposal with such strict form. But why should anyone even create a proposal if documenting a tag via a tag page has more or less no restrictions? C) I think it might be helpful to create a tag page right away to have documentation that can be discussed. (Something like a proposal light.) I just want some kind of recognizability. D) We currently have few direct options for maintaining the wiki to distinguish between pages with wide spread tags and those with not established tags, which becomes more important as more pages are created on the latter. (The only thing is status "approved" and maybe "de facto", but for "in use" it is unclear.) Unfortunately, the taginfo statistics (usage count) are only visible when the page is accessed. They're not helpful in the categories (e.g. "Category:Tag descriptions for XY..."). Whether further, deeper relations are possible here is beyond my knowledge. – Perhaps, as you suggested, we need to go the other way and give the established ones an additional mark. --Chris2map (talk) 15:43, 5 September 2025 (UTC)

"But why should anyone even create a proposal if documenting a tag via a tag page has more or less no restrictions?" - to get feedback and confirm that invented tagging scheme has no major issues and that at least some specific subsection of community likes it (peer review is not magic and does not guarantee good effects, see science, but can be useful, see science) Mateusz Konieczny (talk) 02:56, 4 October 2025 (UTC)

"In discussions, it's often pointed out that there's a wiki page for the tag, so it's good to use" that is just wrong given that we also outright have pages stating "this tag is a horrific mistake for following reasons". When such terrible and wrong argument appears this should be explained to mistaken person, rather than deleting all pages for bad tags Mateusz Konieczny (talk) 02:58, 4 October 2025 (UTC)

I am in favor of second variant. I hate overtemplatification and I used following method when describing one of own inventions: separate section "Popularity" with "Note that as of early 2020 majority of uses of this tag is by a single person in a single city<ref>[[User:Mateusz Konieczny]] mapping in Kraków, Poland</ref>." Mateusz Konieczny (talk) 02:54, 4 October 2025 (UTC)

I've realized that adding another label and box isn't ideal. Therefore, I've decided to scrap my template proposal. It's important that the description on one page clearly explains the tag's origin and use, and links to relevant discussions. – Improvements are still possible in the guidelines and our currently existing tag status (reduce them?). --Chris2map (talk) 18:18, 26 November 2025 (UTC)

This page is overly large - please help

This page is large enough to cause technical issues and we were asked to trim it.

If you see already resolved section: feel free to apply {{Resolved}}

If you see section where you can do something to bring it toward closure: it would be appreciated.

If some section become irrelevant, stuck etc... Maybe you can at least propose there action that could bring it to closure?

Mateusz Konieczny (talk) 20:59, 2 November 2025 (UTC)

Resolved: looks trimmed! Mateusz Konieczny (talk) 05:39, 29 November 2025 (UTC)

Screenshot of Google Maps

Resolved: deleted --Chris2map (talk) 09:08, 23 November 2025 (UTC)

File:Track of izola.png — fair use in this case seems to be dubious.

Removed from https://wiki.openstreetmap.org/w/index.php?title=Tr:LLLMapping_Project&diff=prev&oldid=2918599 - fair use is not applicable at all as it could be easily shown on OSM background and as far as I see nothing required GMaps specifically Mateusz Konieczny (talk) 14:35, 12 November 2025 (UTC)

Images from OpenStreetCam

Resolved: deleted --Chris2map (talk) 18:31, 27 November 2025 (UTC)

File:OSC_nearby_image.gif — If individual contributor must be attributed (same as for Mapillary), we likely can't retrieve necessary info, and can't fix such images. Something B (talk) 11:10, 17 November 2025 (UTC)

The individual contributors / photographers are attributed in the image above the photos. Or did I misunderstand what you meant? --Chris2map (talk) 17:46, 26 November 2025 (UTC)

My mistake, I meant File:OSC selected aggregated detection 2.png. Something B (talk) 23:39, 26 November 2025 (UTC)

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

Resolved: Question was answered. --Chris2map (talk) 19:11, 3 November 2025 (UTC)

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

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

@Bgo eiu: Ideally, MediaWiki would bundle a suitable Web font as part of the Universal Language Selector extension, which is installed here. That would allow users to click on " پنجابی" at the top of the page, then go to " ڈسپلے ترتیباں" and "لپیاں", then change "پنجابی لئی فونٹ چݨو" from "سسٹم فونٹ" to Gulzar. I see that you've already requested the addition of Gulzar to ULS. If a workaround is urgently needed, it might be possible for a user script or gadget to embed a Web font using a massive data: URI in an @font-face rule, but I don't think it would be a good idea to enable by default for performance reasons. An externally hosted font would get around some of that issue, but it would present both privacy and security risks. – Minh Nguyễn ^💬 21:15, 11 October 2022 (UTC)

Ah, I assumed this would have to be implemented separately for different media interfaces, in that case, the Phabricator ticket should be fine. It's not urgently needed; I use an external URI with @font-face in my user settings but this is not really needed in the CSS once that goes through. --Bgo eiu (talk) 23:37, 11 October 2022 (UTC)

@Bgo eiu: I'm not entirely sure about the mobile view. There doesn't seem to be a way to access ULS from there, other than to switch to the desktop view. – Minh Nguyễn ^💬 09:08, 12 October 2022 (UTC)

@Minh Nguyen: Are the ULS hosted fonts accessible from the CSS? I forget to check what things look like in the mobile view because I set everything to desktop mode to get the missing features anyway. That may be something that's hard too do much about short term, it shouldn't be anything that's too much effort on the wiki's part to implement. Google developed the Nastaliq font that iOS includes by default, it could be a matter of finding the right Android developer's e-mail address. --Bgo eiu (talk) 03:55, 14 October 2022 (UTC)

@Bgo eiu: Not sure, but you can use the mobile view from your browser and inspect the loaded fonts in your browser's Web inspector. It could be that the fonts do load despite a missing ULS UI. The mobile view does load gadgets and user scripts like normal. – Minh Nguyễn ^💬 02:13, 2 November 2022 (UTC)

Unicode conversion ready for testing

Resolved: Wiki has been updated on 2025-11-30, https://github.com/openstreetmap/operations/issues/373 --Chris2map (talk) 18:37, 1 December 2025 (UTC)

The operations team has experimentally converted the test wiki to a different Unicode encoding. This is expected to fix various longstanding issues, such as the inability to insert emoji and certain Chinese characters into a wiki page in literal form without truncating it or triggering errors. They need help testing the results of the migration on the test wiki to iron out any bugs before running the same migration on this wiki. Please help test Unicode usage everywhere you can, not only page contents but also page titles, edit summaries, user names, and more. – Minh Nguyễn ^💬 17:55, 29 May 2025 (UTC)

License of the Osmarenderer icons

File:Theatre.png - seems to be Osmarenderer icons, but license is missing and I am not sure about threshold of originality. Something B (talk) 18:30, 9 December 2025 (UTC)

Resolved: Replaced and deleted after contact to uploader User:David.earl via message on OSM. --Chris2map (talk) 18:59, 9 January 2026 (UTC)

Dubious license for TeXet_NaviPad_TM-7055HD_3G.png

File:TeXet NaviPad TM-7055HD 3G.png — this file likely from advertising, and not work of the uploader, and unlikely is {{PD-self}}. Something B (talk) 09:55, 25 November 2025 (UTC)

I agree, for now I removed it from https://wiki.openstreetmap.org/wiki/Template:User_teXet_NaviPad_TM-7055HD_3G Mateusz Konieczny (talk) 07:29, 26 November 2025 (UTC)

The uploader states that all photos were taken by themselves (device photos and wallpaper), User_talk:Зелёный_Кошак#File:TeXet_NaviPad_TM-7055HD_3G.png, and I think the use / display of the icons on the screen is OK and no reason to delete that image. --Chris2map (talk) 14:52, 12 December 2025 (UTC)

@Something B and Mateusz Konieczny: How do we proceed here? I would leave it at that and keep the file. --Chris2map (talk) 17:57, 8 January 2026 (UTC)

Weak keep. Maybe no reason for deletion. Something B (talk) 19:19, 8 January 2026 (UTC)

https://commons.wikimedia.org/wiki/Commons:De_minimis may or may not be applicable. I would record claim of use that they authored background and photo, note proprietary icons. I have no strong opinions about deleting Mateusz Konieczny (talk) 06:19, 9 January 2026 (UTC)

Resolved: added note to filepage, and link to discussion. --Chris2map (talk) 16:09, 16 January 2026 (UTC)

How often is taginfo in infoboxes supposed to be updated?

Resolved

e.g. I'm looking at pole:maxload=* and its infobox is still saying "This tag does not appear in the OSM database", even if taginfo itself at https://taginfo.openstreetmap.org/keys/pole:maxload is seeing them just fine for some time (some were entered more than two weeks ago). I've tried purging the cache with no results.

Is it due to low usages of the key, infrequent updates of taginfo to infoboxes, or did something break? --mnalis (talk) 05:33, 25 January 2026 (UTC)

There was a mistake at the page Key:pole:maxload with the parameters of the infobox template. "value" was set with "value=*". But for key descriptions there should be no parameter "value" at all. I've just removed it and now it works. --Chris2map (talk) 06:56, 25 January 2026 (UTC)

PS: Update is generally daily, sometimes 1 or 2 days get skipped. Data can be newer than what the timestamp in the tool says. --99 tabazan (talk) 11:01, 25 January 2026 (UTC)

Request deletion of duplicate image

Resolved: file deleted [9] since copy on Commons is in use now. --Chris2map (talk) 16:45, 29 January 2026 (UTC)

special:fileduplicatesearch/jewelry.jpg

I have uploaded file:jewelry.jpg to Wikimedia Commons with the more specific name file:jewelry in Muswell Hill.jpg; the licensing was compatible. Pinging @Harry Wood: as uploader. — Arlo James Barnes (talk) 06:25, 14 January 2026 (UTC)

Deleting the file would not be strictly necessary, as it meets all the required criteria, especially the inclusion of a copyright / license information. Before deleting, all uses must be removed or replaced. If you suggest deleting the file, please update and replace all links to it. The standardized way to nominate a file for deletion is, as with article pages, the placement of templates Delete proposal or Delete. --Chris2map (talk) 07:09, 18 January 2026 (UTC)

Okay, if it's fine to have duplicates then no need to delete the 2013 upload. I thought I had remembered discussion about trying to tidy the images on-wiki, but that was probably just about images with unclear licensing, which as you say is not the case here. I swapped all uses (except Polish, not sure where that text is being kept). — Arlo James Barnes (talk) 22:24, 20 January 2026 (UTC)

Email notifications for minor changes changed?

Resolved: Seems to be solved, 3 February 2026 (UTC), (--Chris2map (talk) 08:36, 22 February 2026 (UTC))

In the past, I had the impression that I always received an email notification when someone changed a wiki page that was on my watch list, even if they marked the change as "minor". Now I have the impression that I haven't been receiving notifications about minor changes lately. Has something been changed? Unfortunately, some wiki editors seem to have the habit of marking even significant changes as "minor". There is also an option "Mark all edits as minor by default" in the settings. --Hufkratzer (talk) 10:52, 1 February 2026 (UTC)

There is a setting “Email me also for minor edits of pages and files” in the user preferences. I can't tell if the default setting has changed. --Chris2map (talk) 11:05, 1 February 2026 (UTC)

I have this option enabled continuously for years, and I used to think that it worked. But lately, it seems to me that at least sometimes it no longer works. We can make a test: Make a minor edit to User_talk:Hufkratzer and I will tell you if I got a notification or not. --Hufkratzer (talk) 14:24, 3 February 2026 (UTC)

I received a notification for this minor edit; it worked as intended. --Hufkratzer (talk) 16:27, 3 February 2026 (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. [10][11] Validators can't use the taginfo API to flag usage of deprecated tags, so every editor has its own logic. [12] I don't mean to disparage taginfo: its specialty is analyzing the OSM database, not making the wiki more digestible. But the scraper does keep us from modernizing templates like {{ValueDescription}}. We can't for instance remove the redundant "File:" from |image = and |osmcarto-rendering-area = or automatically derive |key = and |value = from the page title without having to also hack on Ruby code.

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

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

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

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

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

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

Data items - displaying P16 in Wiki lists

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

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

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

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

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

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

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

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

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

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

Thank you for you detailed input Chris2map !

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

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

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

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

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

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

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

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

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

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

Detecting differences between infoboxes in English and translated pages

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

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

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

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

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

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

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

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

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

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

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)

Why is installing this extension blocked? I haven't seen any dissenting voices. maro21 23:35, 12 December 2023 (UTC)

I opened a request for this extension as well as an alternative request for Extension:DynamicPageListEngine, which might address the performance concern I noted above while giving us more customization options via Lua. – Minh Nguyễn ^💬 05:33, 1 August 2024 (UTC)

Was there any update to these? I see a comment in June by @User:Minh Nguyen but crickets for quite some time otherwise. GA Kevin (talk) 18:12, 20 August 2025 (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 ([13][14]).

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)
9. Should we allow CC-BY-NC-ND / CC-BY-NC / CC-BY-ND media at OSM Wiki? Mateusz Konieczny (talk) 22:43, 1 August 2022 (UTC)

At first reflex I thought no. But then I thought about where a problem would arise in that. The wiki is not a commercial project, so using these licenses would be OK. Also, if there is a link to a wiki page from other websites or services. I think normally a wiki page and the images it contains are not reused, but only linked or reproduced. - However, the first problem is when someone does reuse wiki content in such a way that it becomes part of a commercial service. We can't control that. The second problem is that images not only appear on wiki pages, but can also flow into databases, e.g. via taginfo or in the data items. Then commercial use is very likely. And how do we want to regulate and control this, so that in some cases the license is OK, but not in others. I can't imagine how this is supposed to work in practice. The mixing, if we allow the -NC and -ND licenses, is unavoidable. So in the end I would say that we should avoid these license variants. --Chris2map (talk) 20:26, 2 August 2022 (UTC)

The worst part for me is that "commercial" is not really clear. Lets say I am making an OSM editor and got grant supporting its creation. Can I use such images? Mateusz Konieczny (talk) 06:38, 3 August 2022 (UTC)

Extra questions (added later)

1. How much of imagery is allowed? Is small snippet of unknown imagery like at 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)

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)

Regarding the technical side, I have not found a mechanism to implement this using abuse filters. Just wanted to let you know ... --Tigerfell  (Let's talk) 13:38, 3 August 2022 (UTC)

@Tigerfell: adding "Marco Verch" to abuse filters? maro21 21:21, 24 January 2024 (UTC)

Very interesting article. I'll quote the most important part, for people who didn't want to read such a long article:

The original version of the CC license stated that the license would “terminate automatically upon any breach.” That meant that if you failed to live up to the license terms in any substantial way, you were no longer a licensed user of the copyrighted work. Any uses you had made of that work were no longer permitted under the license, so unless you had another basis for using it (for example, if your use qualified as “fair use”), then you were now infringing copyright.

Recall that “willful” copyright infringement carries a statutory penalty of $150,000.

These two facts — automatic termination on breach, statutory damages of $150,000 — created the copyleft troll

Copyleft trolls are a combination of entrepreneurial individual extortionists and law-firms that actively recruit would-be extortionists with a pitch that’s very similar to the copyright troll’s come-on: sign up with us and we’ll find people who made minor errors in their use of your Creative Commons works, and then send them a speculative invoice for a “license,” on threat of a copyright lawsuit that could run them $150 grand plus legal fees. We’ll split the take.
[...]
The 2.0 license has the strictest attribution requirements, making it easy to slip up.

I think the only things we could do is to set a filter on the words "Marco Verch". After all, we can't forbid the use of the 2.0 license. We can only suggest and warn by providing a link to this article.

So there's no problem if a user uploads his work and gives it a CC 2.0/3.0 license, but only if he copies it from somewhere, marks the attribution incorrectly and unluckily ends up with a copyleft troll.

See also:

• https://commons.wikimedia.org/wiki/Category:Images_by_Marco_Verch
• https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Files_by_Larry_Philpot

maro21 21:21, 24 January 2024 (UTC)

" we can't forbid the use of the 2.0 license." - we can do exactly this if we would want (or announce that no new files on this license will be allowed)Mateusz Konieczny (talk) 12:26, 25 January 2024 (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)

I kind of worry that installing piles of extensions will make even harder to maintain wiki installation Mateusz Konieczny (talk) 11:08, 10 October 2023 (UTC)

 Support erutan (talk) 22:23, 25 February 2023 (UTC)

Having a proper Lightbox would make it a lot easier to have multiple photo examples for key values. Being able to have a set of thumbnails where you can click one to load a modal with caption + full size version that you can just then move onto the next one is way better than opening a bunch of full size versions in new tabs and looking through all the attachment file clutter for the caption. In many cases this is ignored, or people have to cram it into tables which quickly ends up bloating the page.

This topic has been open for three years now and I think it would be very useful to have the ‘Extension:Media Viewer’ on this wiki, it would benefit the whole community. So can we install it? — Koreller (talk) 17:36, 4 May 2025 (UTC)

Thanks for the reminder. I'm also in favor of installing this extension. There are no objections and no one was against it. At the moment (May 2025) we are working on installing two other extensions to the Wiki - it turns out that it wasn't enough to install them, because once they were installed they didn't work, so we have to configure them, and that takes some time. I think that once we deal with these two, we'll get around to installing more extensions, as several suggestions have already been made on this page. maro21 20:48, 10 May 2025 (UTC)

So, they are installed but not functional? Mateusz Konieczny (talk) 08:45, 13 August 2025 (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)

I think it shouldn't be too much effort to replace the OSMCalWidget by the External Data extension, and move all styling to the Lua code for everyone to adjust as needed. I've uploaded some proof of concept code here, along with the Lua code, a Wiki page, and a screenshot: https://gist.github.com/mmd-osm/7ef5f6254d7b84e52473757ad133ddd9 ... Let's bring the power back to the Wiki users. Mmd (talk) 18:09, 12 August 2022 (UTC)

Updating the wiki's license

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

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

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

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

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

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

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

GFDL license was modified to allow this - see 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)

CC-BY-SA-4.0 may be added in new changes, but version 2.0 will still apply (CC-BY-SA-4.0 AND CC-BY-SA-2.0). Something B (talk) 09:05, 10 November 2023 (UTC)

Is anyone interested in working on this? Or at least planning? Not sure is it worth keeping it on this page in the current state as it is (1) a very large project (2) not confirmed that there is a clear support for this Mateusz Konieczny (talk) 06:21, 2 September 2022 (UTC)

See https://lists.openstreetmap.org/pipermail/talk/2022-September/087763.html for mailing list posting Mateusz Konieczny (talk) 03:20, 30 September 2022 (UTC)

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

Updating license of media files

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

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

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 [15], [16], [17], 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)

Sorry for the late reply. The correct addressees are the Sysadmins via GitHub because this is where those settings are adjusted. The tricky thing is that the other wikis are either write-protected [18] or even read-protected [19][20] and I do not have access to any of them. So, I can not actually see what I am doing there when I propose a configuration change for all wikis. The last restructuring of the wikis' configuration files created a separate section of configuration for this wiki (location in the source code). I opened two PRs yesterday. If they merge them I can open another one and put the previously discussed code in there. I already created Abuse filter 16 which reminds users of missing licence templates and links to the media file license chart and I changed an interface message to point out that the users have to add the licence template themselves. --Tigerfell  (Let's talk) 15:07, 18 December 2022 (UTC)

See how it looks like for the user: https://community.openstreetmap.org/t/finding-new-images-for-osm-wiki-help-welcomed/5423/17?u=mateusz_konieczny Mateusz Konieczny (talk) 16:15, 14 November 2022 (UTC)

Install the WikibaseCirrusSearch extension

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

• haswbstatement:P2=Q2 haswbstatement:P6=Q15 -hasdescription:es would find every data item about an approved (Q15) OpenStreetMap tag (Q2) that is missing a description in Spanish. (SPARQL)
• haswbstatement:P2=Q2 hasdescription:es -haswbstatement:P31 would find every data item about a tag that has a description in Spanish but no article yet – good candidates for new articles. (SPARQL)
• haswbstatement:P2=Q2 haswbstatement:P16 would find every data item about a tag value that has an invalid permanent key ID (P16) statement instead of a permanent tag ID (P19) statement. (SPARQL)
• haswbstatement:P28=*[P48=Q21329] would find every data item with an image (P28) limited to region (P48) United States (Q21158). [21]

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

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

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

I have just my traditional worry that already existing parts are not working well and that adding piles of extension will make this wiki even worse frankenstein Mateusz Konieczny (talk) 04:43, 27 July 2022 (UTC)

I strongly support. Do it. maro21 20:42, 19 April 2023 (UTC)

@Minh Nguyen:, could you please submit this extension for installation? There have been no dissenting voices and it will not affect the Wiki in any way. Would be very helpful for me. maro21 19:44, 27 June 2023 (UTC)

@Maro21: https://github.com/openstreetmap/operations/issues/903 – Minh Nguyễn ^💬 21:03, 27 June 2023 (UTC)

Brief update 2025-11-03: Trying to install it ended up with malfunction (see previous github issue 903). --Chris2map (talk) 17:52, 3 November 2025 (UTC)

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

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

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

Isn't there also the option of tolerating images that are not available under an open license as long as we don't have a reason to suspect copyright violation and cannot easily replace the images? Today, someone mentioned on talk-de that photographs of historical OSM events were deleted because the uploader wasn't the photographer and was therefore not able to grant permission to use the image under an open license, even though permission to use the image on the OSM wiki had been obtained at the time, and that doesn't seem ideal. --Tordanik 12:32, 6 August 2022 (UTC)

See this discussion. The plan is to avoid deleting valuable irreplaceable images where it can be assumed that user licensed it like other OSM Wiki contributions. And images such as File:SotM2021 group photo of some participants version3.jpeg which are irreplaceable and were made in a good faith, even if not fully OK.

"even though permission to use the image on the OSM wiki had been obtained at the time, and that doesn't seem ideal" - in such case (if it can be assumed that author was aware that they permit also commercial use and so on) - uploader should respond about that and ideally note it on the file description.

Which specific image should be preserved but was deleted or marked as awaiting deletion? File:Osm owl 2010-09-27 P9276171.JPG was linked but it fits neither description

What can be done and would be helpful

• Process own files and if someone is the author - apply clear license (to make them actually reusable, note that images with unclear licenses are far less useful and may be deleted in future when different decision will be taken or needed due to legal situation)
• Review files on this list and User:Mateusz Konieczny/friendly and this category - overall over 25 000 files await processing.
• Consult someone whether we actually can knowingly keep files where people are likely to be unaware about license or uploading random files found on the internet, but it is not blatantly obvious (LWG?) - note that question whether we want to keep such files is separate
• Review files marked as problematic and help with contacting their uploaders
• Write template text for file which are kept despite lack of clear license
• Create that template
• Apply that template (mentioned in the previous step) where applicable and to nothing else
• Help in reviewing what was done - I definitely made some mistakes. I spotted some of them when I was reviewing files which I marked 6 months ago as missing licences. For example one of files had license marked on the corner of image itself, so I now applied proper template instead of marking it for deletion. Tigerfell who is basically the sole moderator processing file deletions catches most of remaining ones, but likely not all.
• Let me know how that message that I am adding on talk pages can be improved (without making it even longer and more complex)
• Review of https://wiki.openstreetmap.org/wiki/Category:Labelled_for_deletion also can be useful if someone expects wrong files to be send for deletion

Participating in that discussion linked above also would be helpful

Help would be in general appreciated and is likely to result in better outcomes Mateusz Konieczny (talk) 13:44, 6 August 2022 (UTC) (@Tordanik:)

Some icons without licenses included in many "Kosmos rules" pages,for example File:Vending_machine20.png. This pages maybe not actual anymore, therfore can be deleted? Or we should routinely clean them? Something B (talk) 23:23, 17 November 2023 (UTC)

Enhanced not-found messages for non-English users

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

note: this was extracted from https://wiki.openstreetmap.org/wiki/Talk:Wiki#Enhanced_not-found_messages_for_non-English_users section of "Enhanced not-found messages" in "Redundant pages for "building block" tags"

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

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

Update 2025-11-03: Since running the Translate extension will take a while longer, more manual translations were added. For now, there are enhanced MediaWiki:Searchmenu-new and MediaWiki:Noarticletext in /ar /de /el /es /fi /fr /it /ja /nl /pl /pt /ru /uk /vi /zh-hans /zh-hant. --Chris2map (talk) 19:06, 3 November 2025 (UTC)

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

Unresolved

See https://wiki.openstreetmap.org/w/index.php?title=User_talk:B-unicycling&diff=2387619&oldid=2387482

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

The issue still exists. I don't know on which skin and view is the option "I created the file myself" because I can't see it in my settings but users report the issue:
There was an option select that I created the file myself, which I did. Then it errored on me and threw me back to tick whether I created the file myself or not. I had it ticked that I created it myself and then it threw me back to tick it whether I created it myself or not. This went on for about 20 minutes - after 100 failed attempts I simply selected then I didn’t create it myself - so at least I could upload it. --User:Hike&Map
maro21 22:44, 30 September 2023 (UTC)

The option is offered if you do not first upload an image before using it in an article but edit an article and click on the insert media icon in the edit tool bar and then choose upload from the poped-up window. --Chris2map (talk) 23:39, 30 September 2023 (UTC)

Ohh, I see, thanks.
So maybe we should change the message if it doesn't work. maro21 10:58, 1 October 2023 (UTC)

Missing language description at compound pages

any idea why some rare languages miss descriptions?

For example https://wiki.openstreetmap.org/wiki/Key:name:mnc https://wiki.openstreetmap.org/wiki/Key:name:sat https://wiki.openstreetmap.org/wiki/Key:name:man https://wiki.openstreetmap.org/wiki/Key:name:kio https://wiki.openstreetmap.org/wiki/Key:name:yuf https://wiki.openstreetmap.org/wiki/Key:name:mhj https://wiki.openstreetmap.org/wiki/Key:name:lud https://wiki.openstreetmap.org/wiki/Key:name:sat

See https://iso639-3.sil.org/code/yuf https://en.wikipedia.org/wiki/Havasupai%E2%80%93Hualapai_language confirming code assignment (the same applies to other codes listed here)

Compare https://wiki.openstreetmap.org/wiki/Key:name:dak https://wiki.openstreetmap.org/wiki/Key:name:tyv with compound pages generated

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

@Minh Nguyen:

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

@Mateusz Konieczny: There are multiple issues:

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

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

I guess we should delete https://wiki.openstreetmap.org/wiki/Item:Q14162 as pointless AND causing problems. Any idea how we can get data item deleted? Mateusz Konieczny (talk) 20:00, 11 October 2022 (UTC)

You can tag the talk page with {{Delete}}. Make sure to note that you'd like the item deleted, not just your request for deletion. ;-) Before outright deletion, we should ideally attempt to figure out the intention behind the key's usage. If it does turn out to be a typo for seats=*, then we should change the status (P6) to deprecated (Q5061) and add a replaced by (P17) to the correct key. I've modified Module:Tag to avoid using items that redirect, because we normally don't deprecate just one component of a key. – Minh Nguyễn ^💬 20:36, 11 October 2022 (UTC)

"Do you know of any references for making this order of precedence more accurate?" - no, and I am tempted to just create wiki pages for such name:lang cases. At most I can imagine maintaining list of tag parts which presence makes language context more likely (name, note, description...) Mateusz Konieczny (talk) 20:02, 11 October 2022 (UTC)

I think that would be a useful wiki page to put together, not only for this 404 page but for a lot of other things too. Eventually I want Module:Tag to take over {{Tag}}; it could come with smarts to decide whether to link a key part or not, so people don't have to choose between |: = and |subkey =. Editors could also adapt this list to internationalize more fields besides name=*. It would be a logical extension to Order of key parts. – Minh Nguyễn ^💬 20:36, 11 October 2022 (UTC)

Order of key parts may be related Mateusz Konieczny (talk) 21:01, 11 October 2022 (UTC)

"I think the next step would be to file a bug report against the MediaWiki-extensions-CLDR component." - not sure is it worth doing, in my experience MediaWiki phabricator is a black hole where you at most get WONTFIX. Mateusz Konieczny (talk) 20:05, 11 October 2022 (UTC)

It's a big project. Language-related issues have a better shot at getting looked at, because internationalization matters so much to the Wikimedia community. At least someone more familiar with the extension could point out if the issue has been reported before. – Minh Nguyễn ^💬 20:36, 11 October 2022 (UTC)

The extension documentation says you can download the latest CLDR data and it'll use it. Maybe we should ask the operations team to give it a try. – Minh Nguyễn ^💬 20:42, 11 October 2022 (UTC)

Would an updated CLDR address documentation in currently missing languages? Andrew (talk) 21:19, 11 October 2022 (UTC)

@Wynndale: I think that's a different language list, or at least it seems like it based on the different instructions at d:Help:Monolingual text languages and [22] for requesting a monolingual text language. – Minh Nguyễn ^💬 09:03, 12 October 2022 (UTC)

"Feel free to copy these modules if you think the maintenance overhead would be manageable" I will try looking into this. Mateusz Konieczny (talk) 20:11, 11 October 2022 (UTC)

By the way, Module:Languages/config already overrides the language table with a few things we need for this wiki. We could add more to that module, but it's used in {{Languages}}. We had problems in the past when a former contributor attempted to turn this wiki into the go-to source for CLDR corrigenda, so I've hesitated to start down that road again. If we're able to copy Wiktionary's modules verbatim, then we could tell people to hash out their disagreements with CLDR or ISO upstream at Wiktionary. – Minh Nguyễn ^💬 20:36, 11 October 2022 (UTC)

@Minh Nguyen: thanks for investigation! Mateusz Konieczny (talk) 20:11, 11 October 2022 (UTC)

Category:User images

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

I'm actually in favor of moving the images to Category:Images depicting OSM Wiki editors but this category should be categorized in Category:User images. — Koreller (talk) 07:03, 7 December 2022 (UTC)

+1 — Chris2map (talk) 08:36, 7 December 2022 (UTC)

@Koreller: what kind of content will qualify for Category:User images but not for Category:Images depicting OSM Wiki editors? Mateusz Konieczny (talk) 09:08, 7 December 2022 (UTC)

@Mateusz Konieczny I'm talking about category. My idea is to have Category:User images as a super category which would contain Category:User trombinoscope and Category:User categories
(NB: Finally, I prefer the name of "Category:User trombinoscope" than "Category:Images depicting OSM Wiki editors") — Koreller (talk) 18:13, 7 December 2022 (UTC)

So "Category:User trombinoscope" would be for user account trombinoscope? And create separate category for each user account with images? Mateusz Konieczny (talk) 09:29, 8 December 2022 (UTC)

Yes I think it's a good organization

• "Category:User trombinoscope" : for image depicting a user, and
• "Category:User images" : to allow the user to have a category for all the files they have uploaded

(and categorize its two categories in "Category:User categories") — Koreller (talk) 09:33, 10 December 2022 (UTC)

The term "trombinoscope" is confusing to me. I do not know this term. I would like to have the term "images" in the new name of the category for user images showing user portraits, like suggested by Mateusz or something similar. - With the second part, a seperate category for each user containing images the user uploaded, there is Special:ListFiles. --Chris2map (talk) 10:27, 10 December 2022 (UTC)

Ah @Chris2map: why "trombinoscope" will be confusing for you ? And do you have a suggestion for naming two categories, one with images uploaded by users and the other for their portraits ?
In fact, the problem may be more to know what we would put behind the "User images" category, images depicting OSM Wiki editors or images per user.
I also find Special:ListFiles to be very inadequate, and very inconvenient for navigating through my own contributions, and it is for this reason that many users on Commons use a category like "Files by User:...", like me, and it's really valuable for files who can be upload on Commons. — Koreller (talk) 10:20, 11 December 2022 (UTC)

@Koreller: That was meant literally - I've never heard the word "trombinoscope" before. BTW, Special:ListFiles is not to bad. You can sort by date [23]. But feel free to use Category:Files by User:Koreller. I have absolutely no objections to that. - I can imagine that we use Category:User images as superordinated and put those images showing wiki editors in Category:Images depicting OSM Wiki editors. Everything else could be divided up into categories per user as wish. --Chris2map (talk) 11:59, 11 December 2022 (UTC)

Is "trombinoscope" even word in English? It seems to be in French Mateusz Konieczny (talk) 00:51, 12 December 2022 (UTC)

I think the English concept of a trombinoscope would be a directory of people with photos. There isn't really a specific, single English word for that though. Trombinoscope or otherwise. At least not that I'm aware of. --Adamant1 (talk) 02:00, 12 December 2022 (UTC)

I think that "face book" used to be used, but that meaning got eaten by FB (that based its name on this). And note that this photos can be not necessarily face - it may be full person, shadow of person etc Mateusz Konieczny (talk) 13:10, 12 December 2022 (UTC)

Hmmm, I've never heard the term before. But you might be right. In that case it just sounds like a photo album. The impression I get from the small amount of research I've done on it is that a trombinoscope is different somehow from just a regular photo album. Although I can't really say how, but that's at least the impression I get. -Adamant1 (talk) 02:06, 13 December 2022 (UTC)

I support migrating Category:User images to Category:Images depicting OSM Wiki editors. maro21 21:00, 19 April 2023 (UTC)

I started final migrations steps and realised that it can be misinterpreted as "images of software used to edit OSM Wiki" - Category:Images of people who are OSM Wiki editors ? Mateusz Konieczny (talk) 17:08, 3 November 2023 (UTC)

Maybe Category:Images depicting OSM Wiki contributors? "Images depicting OSM Wiki editors" is indeed ambiguous, but because there is only one Wiki editor (editing program), the word "editor" could be understood from the context. maro21 17:54, 3 November 2023 (UTC)

I like Category:Images depicting OSM Wiki contributors. --Chris2map (talk) 20:40, 16 December 2023 (UTC)

Maybe it would be possible to do the editing with a bot, so as not to waste time? maro21 21:33, 17 December 2023 (UTC)

Yes, and I am planning to do this (though if someone else would do this with I would be very happy) Mateusz Konieczny (talk) 09:52, 18 December 2023 (UTC)

Prefix versus key sites ...

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

• 1.) {{tag|proposed|:=lanes||2}} links proposed to the Key:proposed page. This may be confusing for many readers. So shouldn't it link to prefix proposed:*=*? See Cs:Předpona_životního_cyklu.
• 2.) {{Tag|abandoned|subkey=shop|doityourself}} links abandoned to the Key:abandoned page. So shouldn't it link to prefix abandoned:*=*? See Pl:Key:abandoned:*.

• 3.) Data items: Some data items contain a links to the Prefix page, for example in Item:Q5380 there is a link abandoned:. On the Tag:highway=abandoned page that loads data from Item:Q5380, a link will be created in the format abandoned: instead of abandoned:*. Will the code be reprogrammed for this, or is the solution to create redirect pages to a prefix for other languages?

• 4.) Redirects: Should ES:Key:abandoned contain a redirect to the eng version of the abandoned page or should I have it deleted? It now links to the Prefix page instead of the key information. Such links to the English version of the site are created automatically even without these redirects, so I find such a redirect unnecessary and create the impression that there is a page in the appropriate language, even if it is not. -- Lenochod (talk) 20:46, 17. January 2023 (UTC)

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

Some success with 1. and 2.: See {{User:Chris2map/Sandbox|proposed|:=lanes||2|type=prefix}} and {{User:Chris2map/Sandbox|abandoned|subkey=shop|doityourself|type=prefix}} ( {{User:Chris2map/Sandbox|abandoned|:=shop|doityourself|type=prefix}} ) --((sandbox changed; permalink for history))--. Is it the way it should be? - It is done by adding option type=prefix to Template:Tag. For now, this is a test on my sandbox. If it works for you, we could update {{Tag}} and put "type=prefix" in {{Prefix}} so you wouldn't have to write the type=prefix in the tag link. --Chris2map (talk) 23:05, 18 January 2023 (UTC)

@Chris2map: The result looks OK, you can insert for me. -- Lenochod (talk) 13:25, 20. January 2023 (UTC)

@Aharvey:@Lyx:@Minh Nguyen:@Push-f:@Reneman:@Tigerfell:@Wynndale: Hi! Before I get started editing that heavily used template, I want to ask for double-checking the suggested changes to {{Tag}}, that I'm testing on User:Chris2map/Sandbox&oldid=2467559 to fix linking to key prefix pages named with " :* " (see discussion above) - {{#ifeq:{{{type|}}}|prefix|[[{{TagPagename|lang={{{kl|}}}|1={{{1<noinclude>|name</noinclude>}}}}}:*|{{{1<noinclude>|name</noinclude>}}}]] - Main queries: Any errors? Any performance issues? - I would welcome any feedback! --Regards, Chris2map (talk) 14:18, 20 January 2023 (UTC)

I did not spot anything. While reading I was just wondering if it would be better to name the prefix pages Prefix:a to distinguish them from the keys. --Tigerfell  (Let's talk) 23:12, 20 January 2023 (UTC)

ad 3) Even if I'm not happy with, we should add all redirects (Key:prefix: -> Key:prefix:*) and create those pages (with ":"), IMHO, to make sure linking works in any cases. --Chris2map (talk) 08:03, 22 January 2023 (UTC)

ad 1) and 2) {{Prefix}} Template:Prefix has been updated. --Chris2map (talk) 08:59, 19 February 2023 (UTC)

• 5.) The prefix of a wiki page with multiple language versions is connected to the data items only for the English wiki page, but not for the others. For example: service:vehicle:*, ruins:*, ruined:*, removed:* ... -- Lenochod (talk) 19:16, 28. July 2023 (UTC)

This also applies to other articles: keys and tags, not just prefixes. There can be only one link between the data item and the article and every data item links to the English version. maro21 19:55, 3 August 2023 (UTC)

I did not find a single Data Items page that was the same twice. There are for example Item:Q5698 and Item:Q13978, but the first is for the prefix and the second for the Key page. -- Lenochod (talk) 19:58, 7. August 2023 (UTC)

@Lenochod: What maro21 was trying to explain is that you cannot associate a data item with a translation of a page, since each translation is a separate page and you can only associate one page with the data item. So we link the English pages. Therefore, there is a link in the menu on the English page, but not on the translated page. I started a draft for a data item link in every tag description box, see Talk:Data items#Link_to_data_item_in_description_box. --Chris2map (talk) 17:33, 14 August 2023 (UTC)

• 6.) Would it be possible to edit {{TagKey|...}} for prefix links? -- Lenochod (talk) 19:38, 28. July 2023 (UTC)

Wordmark in Vector New version

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

PS: The actual header without logo : Manjiro5 (talk) 15:00, 17 May 2023 (UTC)

I agree ! — Koreller (talk) 22:57, 18 May 2023 (UTC)

I agree, too! --Chris2map (talk) 07:35, 19 May 2023 (UTC)

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

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

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

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

On mediawiki.org those are two seperate image files, one the logo and one the wordmark. For quick start, I suggest to use same logo like with the old default skin and the same raw wordmark style like on osm.org. For that purpose I uploaded a svg-version of the wiki logo and a svg wordmark . - Later on, we can discuss an enhanced styling, e.g. with the proposals from Manjiro5. --Chris2map (talk) 17:53, 2 June 2023 (UTC)

File:OpenStreetMap Wiki wordmark raw1.svg seems fine for me Mateusz Konieczny (talk) 11:47, 4 January 2024 (UTC)

That logo and wordmark would work great and it brings us one step closer to making Vector2022 the default. I’m surprised that it’s been two years and this incredibly simple change has not been made yet. I think it’s time to ask a sysadmin. Mxdanger (talk) 16:47, 6 June 2025 (UTC)

Thanks for bringing this up again. Before I forward the request to the operations team I try to clarify, what requirements (image sizes, filetypes, etc.) we need. On mw:Manual:$wgLogos it says 50x50 px for SVG logo. I'm not sure if we still need PNG versions of logo and wordmark. I think we simply / only can set

	'icon' => "/static/images/icons/openstreetmapwiki.svg",
	'wordmark' => [
		'src' => "/static/images/mobile/copyright/openstreetmapwiki-wordmark.svg",
		'width' => 135,
		'height' => 20,
	],

Tests with the SVG files I suggested above did work (manipulated live in the browser in page source code), see
screenshot logo + wordmark
screenshot logo + wordmark in dark mode
screenshot logo only (text wordmark).
While creating a SVG logo file scaled to 50x50px I'm wandering if we should make a less complex icon (less of gradients and transparencies). I don't know if this could be a question of performance. Does anyone here have any experience with this? --Chris2map (talk) 13:30, 7 June 2025 (UTC)

@Chris2map: The full OSM logo is a very complex SVG, but I'd be less concerned about performance than about compatibility with various browsers. – Minh Nguyễn ^💬 20:36, 17 November 2025 (UTC)

Okay, compatibility is an important point. I'm not familiar with SVG browser support. I'll take a look at the SVG logo to see if a simpler version is possible without noticeable visible changes. --Chris2map (talk) 09:19, 23 November 2025 (UTC)

Joining the ranks of administrators?

I mentioned (off-wiki) to @Minh Nguyen: that there were around 60 files in the deletion category, and that I might be willing to help processing them, and was advised to post here as a nomination. So here I am. I've had admin powers at the English Wikipedia since 2005, although I haven't been very active there in years, so I should be plenty familiar with MediaWiki processes. On OSM, I've been a very heavy StreetComplete user for a number of years, and participated in various other OSM-related stuff over time. It's unclear to me what process, if any, there is, so I suppose I'll just end this here. JesseFW (talk) 19:47, 18 June 2023 (UTC)

•  Support Special:Contributions/JesseFW has a demonstrated track record of helping to keep the wiki tidy, and not only in the deletion process. We only have a handful of active administrators, so another couldn't hurt. – Minh Nguyễn ^💬 22:22, 18 June 2023 (UTC)
•  Support as some administrative tasks are backlogged and many of administrators we have are inactive (and ideally someone not active for 5 years would not hold admin rights) Mateusz Konieczny (talk) 08:58, 19 June 2023 (UTC)

• Oppose. I don't support this nomination for an administrator. JesseFW has only been active for 1,5 month and only corrected typos then. He is not yet familiar with this Wiki and deletes correct data, just to keep the external validator happy, even though he was asked not to do so.

He removed the correct data, just so the Taginfo validator wouldn't report an error: [24], [25], [26], [27], [28], [29], [30].

And blanks infoboxes, even though there is no agreement for it: [31], [32].

If someone were to become the new administrator, I would nominate User:Chris2map, who has been active for many years and knows this Wiki very well. maro21 17:15, 20 June 2023 (UTC)

I was looking forward to a relaxing end of the day, switch on OSM Wiki and the message symbols appear. Happy too soon! (Warning: irony in the room.) – First of all, thank you for mentioning me here! I can't say anything about the actual topic of the administrator yet, so I have a few quick thoughts on the discussion points presented. When tools don't work perfectly or aren't usable, that bothers me too. Sometimes it then seems easier to adjust the data. I also try to resist this temptation from time to time, although I am personally inclined to a certain degree for a defined and structured data entry. (We can also think a bit about the programmers among us.) On the other hand, it is desirable to allow users a certain freedom. Restricting use because tools reach their limits is only second best. To be more specific: I think taginfo is a great job and I understand that a lot of time and effort went into it. At the same time, I would be very happy if taginfo would learn a few new steps. (A "+" sign is not alien. Prefixes and suffixes. Data items.) That was the technical point. – In terms of content, as far as the differences of opinion in the cases listed above are concerned, I am sometimes more on one side, sometimes on the other side. With those tag values of the key "source=*", I see no reason not to allow all applicability cases. The fallback would be fine for me in both of those cases. – In my opinion, the deletion of information should be done with special care and, so to speak, respect for those who added the information. Even if the information may not be perfect. I think that also plays into the queue of pages to be deleted and not just too few admins. My impression is that previous administrators tended to be reserved to delete pages and media, since the benefits of deleting and keeping can often be seen as divergent. I'm for a non-aggressive deleting behavior. The removal of content, whether pages or data, should follow an agreement or be discussed, so that traceability or further development arises. – To go back to the discussion about cases such as "source=*": I had also thought about the fallback function of the Module:DescriptionFromDataItem several times (blessing or curse?) and considered turning it off. I hadn't even come up with the idea, e.g. not to specify the applicability for the corresponding keys at all, but only for the individual tag values. That would be an alternative to switching off the fallback function. I think we should discuss that. (Now I've written way too long. Sorry for that!) --Chris2map (talk) 21:04, 20 June 2023 (UTC)

So I’ve been pretty clear in the past about the dim view I take to the manner in which tools like OSMBC and taginfo scrape the wiki, setting arbitrary constraints on wiki content that can turn into a minefield. (Wikis are meant to be freeform!) At a basic level, I never knew that there was any attachment to “?” in infobox parameters, since it historically resulted in exactly the same template output as an empty parameter. If the concern is about the data item fallback, then everyone will expend less energy discussing that in the context of the relevant template or module rather than chasing each other around in edit summaries on individual articles, basically the equivalent of debating something in changeset comments without even using the reply function. It’s good that at least you’re reaching out in a talk page comment as of today. – Minh Nguyễn ^💬 22:04, 20 June 2023 (UTC)

I appreciate Maro's checking up on the edits I've been making addressing taginfo validation warnings, and very much respect his concerns about some of them, and am opening discussions on the relevant pages now. I do want to correct a mis-statement of fact, though. My first edit to the OSM wiki was in 21 January 2018, rather more than 2 months ago. I would also be very glad to have Chris2map be an administrator, if they are so inclined. Regarding deletion -- I would also be very cautious and careful in using the deletion functions; deletions should be rare. In my activity (years ago) at the English Wikipedia, I was rather more of an inclusionist than many. I hope that helps to address the issues raised, and I look forward to further discussion. JesseFW (talk) 22:50, 20 June 2023 (UTC)

For the question-mark-icon discussion, please see Item_talk:Q712.

For the use of a literal plus sign in the tag description for phone=* (and similar keys), please see Talk:Key:phone#Does_the_template_description_need_to_use_a_literal_plus_sign?.

Hi @JesseFW: you mention that you've "had admin powers at the English Wikipedia since 2005", can you give us your Wikipedia username ? Thanks ! — Koreller (talk) 19:13, 6 July 2023 (UTC)

Sure -- I thought I had already, but I see I hadn't. https://en.wikipedia.org/wiki/Wikipedia:Requests_for_adminship/JesseW JesseFW (talk) 14:49, 7 July 2023 (UTC)

•  Support. I think we benefit from additional admin support and if someone is willing to do that, I support it! Pardon for making a statement so late. As for me, I'm currently spending a lot of time on the wiki, but or because of that I don't have much more time for admin tasks. Almost everything I do works without admin rights. This means that I have not yet had ambitions to become an administrator. If support is necessary, e.g. to get simple tasks like requests for page moves processed, I don't want to rule it out. --Chris2map (talk) 17:03, 25 July 2023 (UTC)

• As we're now up to over 300 files in the deletion category, and I successfully resolved (I think) the conflict I had with Maro, and everyone else who has expressed an opinion has been supportive, and it's been over a month, it seems worth bringing this up again. @Minh Nguyen: -- do you have any thoughts on whether consensus has been demonstrated, or what else might be appropriate to help do so? JesseFW (talk) 23:30, 27 July 2023 (UTC)

  @JesseFW: I'm just an administrator; it would be up to a bureaucrat to close this poll and act upon it. – Minh Nguyễn ^💬 07:42, 2 August 2023 (UTC)

•  Support There's definitely a need for more administrators, especially considering how inactive the current ones seems to be, and I don't think I've ever personally had or seen any issues with JesseFW myself. So why not? --Adamant1 (talk) 06:40, 28 July 2023 (UTC)

• Neutral You seem not to notice that I declined numerous of your deletion requests because deleting non-confusing redirects creates work for admins only without any benefit. However, I agree with Minh Nguyen that we need more admins. What do you think about the administrators' reaction to the editing patterns of user Rtfm: Was it adequate? What would you have done? --Tigerfell  (Let's talk) 17:18, 28 July 2023 (UTC)
  • I noticed now; I hadn't noticed that you had declined them previously, sorry about missing that. I'm fine with leaving the redirects if you consider that the confusion I described when tagging them isn't sufficient to justify removing them. Rtfm ... certainly presented a challenging case, and honestly makes me less inclined to accept an offer to be an admin here. If I was faced with a similar situation, I'd likely do similarly to what was done, albeit maybe documenting the bad behavior a bit more clearly, sooner. JesseFW (talk) 17:57, 28 July 2023 (UTC)

@JesseFW: this request for adminship still be actual? Something B (talk) 23:11, 8 November 2025 (UTC)

@Something B: I have limited time available now (new baby), but if the community trusts me with the tools, I'm still glad to pitch in where I can. JesseFW (talk) 01:59, 2 December 2025 (UTC)

Why some tag pages seems to be not indexed by DDG while their data items are high? Can we do anything with it?

See say https://duckduckgo.com/?q=healthcare+sample+collection+openstreetmap&t=ffab&ia=web Mateusz Konieczny (talk) 07:07, 28 August 2023 (UTC)

@Mateusz Konieczny: Key/tag/relation articles have poor SEO, both internally and externally. Just as in DuckDuckGo, proposal pages used to rank higher than the corresponding articles in our own search engine until we shunted the proposals to a separate namespace. If I had to guess, it has something to do with layout and markup of the {{KeyDescription}}/{{ValueDescription}}/{{RelationDescription}} and {{Languages}} templates, which insert a lot of unusable content before usable content in the raw markup. I've started a redesign of the language bar that's functionally complete, except that it probably needs a convenient way to start a translation in a new language. Once that's complete, we could consider removing the template from every page and sticking it in MediaWiki:Sitenotice instead. I also started to refactor the infobox, which could help somewhat, but getting the visual output to exactly match the old template got a bit tedious and I got sidetracked for a bit. – Minh Nguyễn ^💬 10:54, 28 August 2023 (UTC)

Too complex wiki pages

Category:Pages where template include size is exceeded and Category:Pages with too many expensive parser function calls are listing some of problematic pages.

This pages are having so many templates that they are causing technical problems - and take loooooooong time to open.

They should be fixed - ideally by somehow improving templates, not using so expensive templates. But splitting them into multiple, removing not needed content, replacing wiki page with some other form of presenting relevant data etc is an option.

See https://github.com/openstreetmap/operations/issues/1046 where this issue was raised. Note that not all problematic pages are found in these categories, but what we have there definitely should be fixed

Mateusz Konieczny (talk) 07:56, 28 March 2024 (UTC)

One of this pages is https://wiki.openstreetmap.org/wiki/Brandschutz_mit_OSM - is it in German by any chance? Curiously there is also https://wiki.openstreetmap.org/wiki/DE:Brandschutz_mit_OSM - should we delete that duplicate without DE prefix? Is it an attempted translation to English? Mateusz Konieczny (talk) 08:15, 28 March 2024 (UTC)

I commented on https://wiki.openstreetmap.org/wiki/DE_talk:Brandschutz_mit_OSM Mateusz Konieczny (talk) 07:05, 29 March 2024 (UTC)

Talk:Map features is also listed as too large - I archived some sections and marked some as ready for archiving Mateusz Konieczny (talk) 08:52, 28 March 2024 (UTC)

Most of those are translations of Map Features, which is also monstrously long and probably just narrowly escapes the limit. However, I recall it being recently mentioned somewhere (can't find it at the moment) on the Community Forum, and some members said they found it useful to have everything in one place. So, unless we do some major restructuring, I'm not sure how we can reconcile that. Duja (talk) 13:54, 28 March 2024 (UTC)

Following the trail from the github discussion, it was possibly https://community.openstreetmap.org/t/cuisine-tags-in-map-features/5882 Cuisine tags in Map Features. But I still don't see we reached a firm consensus what to do with those. Duja (talk) 14:11, 28 March 2024 (UTC)

Map features too huge

Please take a look at Ko:Map Features or at Map features. How long do these pages take to load on your computer? How many errors do they show?
I see a lot of "Lua error: Internal error: The interpreter has terminated with signal "24"".
These pages are too huge. Aren't they trying to include almost all the Wiki content in one article? Does that make sense?
– Do you want to display a list of all the shops? Here are the solutions:

• Key:shop
• Category:Shops
• Category:Tag descriptions for key "shop"
• https://taginfo.openstreetmap.org/keys/shop#values

And these are probably not all possible solutions.
– Want to display a list of all buildings? Here are the solutions:

• Key:building
• Category:Buildings
• Category:Tag descriptions for key "building"
• https://taginfo.openstreetmap.org/keys/building#values
  

– Want to see what's rendering on the map?

• We have SymbolsTab, LinesTab and AreasTab

Is there a compelling reason why it all has to be together on one page? I think not. When this page was created, years ago, it probably wasn't a problem, because there were fewer tags and no data items. Now the article has grown to such a size that in addition to the long loading time (no one likes to wait long for a page to load, but that's not the only problem), there are technical errors that we can't avoid due to MediaWiki's limitations. There's the Lua bug already mentioned above, but there's also a limitation with data items that only allows 250 references, and at 251 you'll always get the Too many Data Items entities accessed error, even though the other references will display correctly.

So, taking into account: the size of the page, the limitation of the software, unavoidable errors, and the fact that this is a frequently visited page (the English version and the other language versions involved), because the link to it is in the main menu on the Wiki, I propose that in these articles the transclusions of the templates be replaced by links, as it is, for example, on Pl:Obiekty na mapie. This is just one possible solution, quick to implement, but I am open to other suggestions.
Reasons why I think that keeping such a huge article is not good:

• very long page loading
• limitation of MediaWiki software and bugs that we cannot avoid
• we have a very well working search engine and it's easy to find the tags you are looking for
• one can use Taginfo
• this page is not irreplaceable, but it consists of snippets that can be found elsewhere (in articles, templates and category)

I can do it myself, starting with the English version of Map features. Does anyone have a valid reason why the current state should remain? maro21 22:00, 28 March 2024 (UTC)

One can use this pages to search for some term and find it also in descriptions. They are also useful as single page overview of the most important tags. (this is not changing that they are causing serious technical difficulties, see section above - and need some restructuring at least) Mateusz Konieczny (talk) 06:51, 29 March 2024 (UTC)

https://wiki.openstreetmap.org/wiki/Talk:Map_features#Remove_Rendering_column may be a step that potentially can extend life of such pages Mateusz Konieczny (talk) 06:57, 29 March 2024 (UTC)

I agree, and I volunteer to be Someone(TM) to remove it, at least in English version. In the process, I would also like to remove the "Key" column as mostly redundant ― it has the same value for all items in most tables (except for Highways) so it may as well go to the heading. Granted, it won't save much memory but it will save horizontal space and improve readability. I did that recently with Smoothness but reverted myself, unsure about side effects. Duja (talk) 09:31, 29 March 2024 (UTC)

The Rendering column doesn't affect the loading speed of this page, because it doesn't contain templates or references to data items - it is just an image. maro21 14:18, 30 March 2024 (UTC)

That sounds like a good idea because, apart from Map Features, the key pages that include these templates become more usable on mobile devices. --Andrew (talk) 09:50, 30 March 2024 (UTC)

The only compelling reason for the existing all-inclusive one-page solution that comes to my mind is that one can easily get an archive or offline documentation / booklet by saving or printing the page to PDF file. I for myself don't like or use that slow an long page either. --Chris2map (talk) 07:42, 30 March 2024 (UTC)

Then we can create such a PDF and link to it. maro21 14:18, 30 March 2024 (UTC)

And isn't the faster loading of English pages caused by the fact that they use a different display system in the Template? See the difference https://wiki.openstreetmap.org/wiki/Template:Map_Features:craft which is faster and loads things sequentially from the Taglist and https://wiki.openstreetmap.org/wiki/Template:Generic:Map_Features:craft where the table is programmed directly in the source of the page (more complicated/slower). I would see a disadvantage of the faster version, that not everything for different languages will be translated as in the slower version. -- Lenochod (talk) 21:36, 4. April 2023 (UTC)

As possible solution, we can replace {{LL}}, {{Keylink}} and {{Valuelink}} transclusions by links to data items, which are independent from languages, provides basic info, and contains links to actual documentation. Something B (talk) 09:29, 11 April 2024 (UTC)

Removing link completely would be more helpful. Data item pages have only what is infobox and this is not very useful info. And unexpectedly linking it would be confusing at best. Maybe manual direct linking to specific wiki page without using resource-hungry templates would work? Mateusz Konieczny (talk) 12:12, 11 April 2024 (UTC)

It is possible to use [[Special:MyLanguage/Title|text]], e.g house. Something B (talk) 14:28, 11 April 2024 (UTC)

@Something B: Special:MyLanguage only works if the Translate extension is installed. It's one of the many benefits of this extension, but the effort to install it has stalled. – Minh Nguyễn ^💬 22:26, 11 April 2024 (UTC)

The page currently uses {{Keylink}} and {{Valuelink}} in order to link to each key and value, but I think we should replace this usage with old-fashioned {{TagKey}} and {{TagValue}}, which I'm rewriting for better performance. {{Keylink}} and {{Valuelink}} rely on data items to discover translations in other languages. While data items are a good tool for discovering translations of ordinary wiki pages like "Bicycle" and "Tags", I think it's overkill for key or value description pages, which have predictable titles. From MediaWiki's perspective, fetching a data item is equally expensive as checking whether a page exists at a particular title, but there's also a cap on the number of data items that can be fetched per page.

The only current benefit of {{Keylink}} and {{Valuelink}} is that it can fall back to a more closely related language than English without having to check that page's existence. But currently it can only perform language fallbacks based on {{Langcode}} – that is, the language implied by the page name. The page might as well specify a fallback language explicitly, saving everyone effort. MediaWiki talk:Lang#Still To-Do would make it possible for the fallback to be based on the user's preferred interface language, but this doesn't really require data items.

 – Minh Nguyễn ^💬 22:15, 14 April 2024 (UTC)

Possible solution: make link to tag or key page a parameter, with default value equal to English page name. If translated version exists, it is sufficient to add page name as parameter, evaluation is pure static, no Lua calls or checks for page existence (as in {{LL}}). Something B (talk) 11:12, 27 August 2024 (UTC)

---

I don't know whether, in the case of the English Map features page, the loading is prolonged by the number of Commons images or the number of templates. I suppose the images, because there are long loading pages with a large number of images and a small number of templates. Does anyone know which has more impact? It's not likely to be local images, because pages like LinesTab load quickly. maro21 14:36, 30 March 2024 (UTC)

---

In the template Template:Map Features:shop, I removed unnecessary parameterization of parameters that are not translated, and removed 165 same links to Key:shop, on top of that called by the template, which uses data items. The whole thing reduced page loading by about 2.3 seconds, from 6.8 s to 4.5 s. This is just one of the templates nested in [Map feautures], but one of the bigger ones. Maybe I can slim down the templates and reduce the loading time of Map features. I will continue. maro21 15:28, 30 March 2024 (UTC)

---

I have already corrected many Map features subpages, but need some more time to finish writing the summary, which will appear here soon. maro21 20:42, 24 May 2024 (UTC)

https://github.com/openstreetmap/id-tagging-schema/issues/646 is suggesting to create website generated from id-tagging-schema to replace map features, as no wiki solution was found and it continues to be source of annoyance for OWG Mateusz Konieczny (talk) 05:48, 29 November 2025 (UTC)

Deceased users

Stuck: see below Something B (talk) 09:17, 5 November 2025 (UTC)

Recently I became aware, through the Wikipedia Signpost, of a former contributor to this wiki and OSM who has sadly passed away. Wikipedia has a well-documented procedure for respectfully responding to news of the deceased, including protecting their user page (since they won’t be able to respond to any defacement), turning off subscriptions (to avoid spamming their families with irrelevant notifications), and optionally posting an obituary. In some cases, those who had advanced permissions are blocked (since they won’t be able to defend against identity theft). Should we adopt any of these steps here on this wiki? – Minh Nguyễn ^💬 05:42, 6 July 2024 (UTC)

That sounds like a good idea and I think we should set it up that way. I just have one question: Should/can we announce the death of a user (as a reason for inactivity), or should we simply state that the user account has been deactivated? I think the announcement and/or obituary should only be made in cases of public or widely well-known users, or if the relatives approve it. --Chris2map (talk) 15:44, 6 July 2024 (UTC)

@Chris2map: Personally, I'd avoid actively seeking out people to block, but if the administrators become aware of a death in the community, we could do some due diligence (such as checking if weeklyOSM has confirmed a death) and block the account only then. Ideally, we'd leave it to the weeklyOSM editorial team to do any announcement. – Minh Nguyễn ^💬 21:10, 6 July 2024 (UTC)

@Minh Nguyen: Are you (or anyone else) interested in setting up page with procedure for that? Mateusz Konieczny (talk) 11:28, 12 August 2025 (UTC)

@Mateusz Konieczny: I could set up a page basically copying what Wikipedia has, but let's see how the forum discussion plays out, in case there's interest in something broader than technical measures on the wiki. – Minh Nguyễn ^💬 23:48, 21 August 2025 (UTC)

Replacing osm-query template usage with overpass

After looking through a few items on Category:All_articles_with_dead_external_links, many are related to Category:Templates_for_Query-to-map and the underlying tool being unavailable. I am fairly new to wiki editing, and I did not know that osmquery tool but I do know Overpass, so after some looking around the Template:OverpassWizard template is pretty handy as a replacement

See this edit. —Preceding unsigned comment added by Robertgzr (talk • contribs) 23 July 2024

@Robertgzr: The documentation at Template:osm-query points to Template:osm-query2, which is apparently also broken.
They should both be replaced with Template:OverpassWizard, or, simpler still, redirected to it... if only we knew how to substitute syntax properly. Let's wait a bit if anyone familiar with both Overpass and Wiki syntax jumps in.
Meanwhile, I will edit Template:osm-query and Template:osm-query2 to indicate the state of affairs and only display ^{[ dead link ]} rather than that unsightly text. Duja (talk) 09:51, 23 July 2024 (UTC)

(P.S. please sign your posts with four tildes, like this: ~~~~).

DiscussionTools extension

Resolved: Installed! – Minh Nguyễn ^💬 09:09, 26 March 2026 (UTC)

Back in September 2021, I installed the Convenient Tools gadget as an optional gadget so that power users of talk pages here could more efficiently manage the many long discussions that they engage in. However, I left it off by default, because it makes rather invasive changes to the page that conflict with other extensions and introduces many keyboard shortcuts that can surprise users unaccustomed to this gadget.

I only intended Convenient Discussions as a stopgap until the Wikimedia Foundation could complete their Talk pages project for modernizing the talk page experience. Though the project sadly didn't go quite as far as some of the early mockups, it did result in the DiscussionTools extension, which provides multiple significant quality-of-life improvements similar to Convenient Discussions, but with better usability and performance:

• Start a new topic without leaving the talk page. The tool automatically signs your comment for you; no need to correct others' comments with {{Unsigned}} anymore!
• Reply to a comment inline without leaving the talk page. The tool automatically figures out the correct level of indentation.
• Subscribe for notifications when someone comments on a specific discussion section, so you don't have to put the whole talk page and its article on your watchlist. This improvement alone could make tagging discussions run a lot more smoothly.
• All these features work in the mobile skin too.

I'd like to see if the community agrees with me that this extension should be installed here. The DiscussionTools extension reached Stable status this past September, which means WMF considers the extension to be ready for deployment on non-WMF wikis that meet the dependency requirements. This wiki already has the VisualEditor and Echo extensions installed, but the Linter extension would need to be installed. (Linter comes built into MediaWiki v1.40, but we're still on v1.39, so we'd have to install it.)

 – Minh Nguyễn ^💬 23:18, 2 November 2023 (UTC)

Convenient Discussions I didn't really use. But I would give a try to new extension DiscussionTools. --Chris2map (talk) 16:21, 3 November 2023 (UTC)

Will I still be able to write in the traditional way after installing this gadget? maro21 17:00, 3 November 2023 (UTC)

@Maro21: Yes, this time, when developing DiscussionTools, WMF was very careful to leave a light touch. So the talk pages remain in the same place, and there are no changes to the underlying wiki syntax. You can completely ignore DiscussionTools once it's installed, but even so, you'll benefit by not having to deal with others' misindented and unsigned comments. – Minh Nguyễn ^💬 19:07, 3 November 2023 (UTC)

Is it possible to test somewhere how it works? Mateusz Konieczny (talk) 17:24, 3 November 2023 (UTC)

@Mateusz Konieczny: The DiscussionTools extension is now installed on every Wikimedia wiki; you can use it on any talk page that hasn't been converted (mangled, really) into a Flow page. You can also compare Flow and DiscussionTools on Test Wikipedia. – Minh Nguyễn ^💬 19:07, 3 November 2023 (UTC)

Please do install the Discussion Tools extension. I'd be more engaged in wiki discussions if I didn't have to worry about markup and fixing the almost-correct markup of Convenient Tools. Thanks! Partytax 16:20, 8 December 2023 (UTC)

Are you still considering this? It sounds like it would be a big improvement. Osmuser63783 (talk) 06:15, 29 August 2024 (UTC)

+1 After a quick look at the testsite it looks like a well thought extension and in my opinion the benefits (lower threshold to participate in discussions) outrun the concerns. So I support improvement! --Chris2map (talk) 14:50, 30 August 2024 (UTC)

Requested. – Minh Nguyễn ^💬 03:21, 6 March 2026 (UTC)

Installed! – Minh Nguyễn ^💬 09:09, 26 March 2026 (UTC)

Timeless skin

Any chance someone could install the Timeless skin? I use it on the Wikimedia wikis and it's really nice. Kinsio (talk) 16:47, 3 August 2024 (UTC)

I'm sure I've mentioned in before, but I, too, am a long invested devotee of the Timeless skin on a bunch of Mediawiki instances; nothing else compares to it in terms of information density and pure aesthetics. I'd be more than happy to handle the installation as well, if the consensus here is favorable. We do have something of a paucity of options available here as far as skins go. RScholar (talk) 06:42, 20 November 2024 (UTC)

Support from me as well, and as already mentioned in #Add Citizen skin removing the formerly bundled skins Cologne Blue and Modern should be considered as well. HLFan (talk) 22:21, 13 January 2025 (UTC)

Pageview statistics

At the Community Forum, someone asked if we could get a statistics about most popular pages on the Wiki, and I agree it would be useful. User:Mcliquid suggested that we should install mw:Extension:HitCounters. Can we please? Duja (talk) 07:39, 23 August 2024 (UTC)

Maybe https://wiki.openstreetmap.org/wiki/Talk:Wiki#Installation_of_the_%22Extension%3AMedia_Viewer%22_on_the_wiki should be configured first? Or "hCaptcha hidden by "Convenient Discussions" gadget" fixed? Overall, I am sceptical about installing multitude of extensions and gadgets and skins, as each new one has risk of producing bugs in some combination of them Mateusz Konieczny (talk) 08:47, 13 August 2025 (UTC)

Add Citizen skin

I'd appreciate it, if an admin could install the Citizen skin. Also consider using it as the default, since it fits the modern and minimalistic style of openstreetmap.org much better than the current 2010 Vector skin. Also consider getting rid of old and outdated skins, such as "Modern" and "Cologne Blue". It's been created with responsive design in mind and it's labeled as "stable" on mediawiki.org. --Strongly7422 12:41, 30 December 2024 (UTC)

 Support --Chris2map (talk) 17:08, 24 January 2025 (UTC)

It's ok to add more skins but I don't support removing any skins. maro21 18:38, 24 January 2025 (UTC)

Special:ItemByTitle - internal error

Resolved: --Chris2map (talk) 18:57, 2 February 2026 (UTC)

I suddenly get an error when I want to go on Special:ItemByTitle. Anyone else too? --Chris2map (talk) 17:02, 4 February 2025 (UTC)

[7fb0e8355526a8ed564d5860] 2025-02-04 16:52:55: Fatal exception of type "TypeError"

Me too. Duja (talk) 19:11, 4 February 2025 (UTC)

Report on GitHub: https://github.com/openstreetmap/operations/issues/1214. maro21 00:20, 1 March 2025 (UTC)

I propose to archive this section, as it not actionable here. Maybe at most mention it at data items? At least it is not affecting OSM Wiki pages, only data items Mateusz Konieczny (talk) 09:39, 29 November 2025 (UTC)

Thanks a lot to Yurik, and TomH, and others involved, the error with Special:ItemByTitle is gone! Thanks to mnalis for reanimating the issue! --Chris2map (talk) 18:57, 2 February 2026 (UTC)