Talk:Wiki/Archive 9

Add Structured Discussions (Flow) Extension

Resolved: alternative solution was found --Tigerfell  (Let's talk) 12:06, 3 April 2022 (UTC)

openstreetmap/operations/issues/496

Editing talk pages is hard for new/inexperienced users.

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

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

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

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

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

(1) what would be import plan for old talk pages? Mateusz Konieczny (talk) 10:02, 11 January 2021 (UTC)

(2) is there a working export from StructuredDiscussions to standard talk pages if development on it stops? Mateusz Konieczny (talk) 10:02, 11 January 2021 (UTC)

Following up on my impression above: Flow development was put in maintenance mode in 2015 before it gained enough of a feature set to be adopted more widely. [1] Though the WMF left open the possibility of restarting work on it, the general sense in places like Wikidata Telegram is that the extension is a "technological dead end" and that it won't ever be developed any further beyond basic maintenance. At the moment, that doesn't present a practical issue for us. LiquidThreads has also been in maintenance mode for almost a decade, but Translatewiki.net uses it today. Still, I would be wary of relying on something in maintenance mode when we could wait a little longer for the new talk page improvements to mature.

@Mateusz Konieczny: Flow is opt-in: there's a special one-time UI command to convert a talk page to be Flow-enabled, and there's no going back (because the topics end up on disparate pages in a different namespace).

I'm unaware of a built-in way to bring everything back to how it used to be if we decide to uninstall Flow. Ultimately, each topic is a wiki page with a unique identifier as the page title, so it should be possible to archive these pages. However, compiling them back into a standard wiki talk page would require a bot to crawl these pages and some assumptions about how the topics fit together. I really do like the Flow interface, but it's a matter of taste and a rabbit hole that we probably shouldn't go down right now.

– Minh Nguyễn ^💬 01:25, 27 January 2021 (UTC)

I've used StructuredDiscussions or Flow on the www.mediawiki.org website several times last year, assuming that's what it was. I've found it to work a lot like forums - it has the same set of issues with editing and deleting posts. I wrote a message on someone's talk page and couldn't edit it to fix a typo. Eventually I was told by an admin that nobody can edit my post anymore. I also couldn't delete my own double-post immediately after I made it, an admin had to do it. That was pretty baffling.

I've noticed that Wikipedia now has a "reply" button on talk pages, I think that equally well solves the problem of counting the ::::: and wondering where you need to place your message, without introducing the forum moderation-type problems. Hopefully they'll release it to other wikis soon. Rostaman (talk) 15:36, 28 January 2021 (UTC)

@Rostaman: The "Reply" button is part of the talk pages project that the Wikimedia Foundation is actively pursuing as an alternative to StructuredDiscussions/Flow that's much more flexible. It isn't mature enough to install here yet, but it seems quite promising. – Minh Nguyễn ^💬 09:45, 6 February 2021 (UTC)

For future reference, the Reply and New Discussion tools are implemented by mw:Extension:DiscussionTools, which seems like a refreshingly simple extension: backwards-compatible, no special namespaces, and the BetaFeatures dependency is optional. The only downside is that it's currently in beta. If this is a problem, perhaps Commons:User:Jack who built the house/Convenient Discussions would be a good stepping stone, since it's nothing more than a gadget. – Minh Nguyễn ^💬 18:47, 8 March 2021 (UTC)

I'm considering installing Commons:User:Jack who built the house/Convenient Discussions as a gadget here, as a stopgap until mw:Extension:DiscussionTools is ready for primetime. Both extensions are backwards-compatible with the wikitext conventions for replies and signatures. The two extensions seem to be capable of coexisting; Convenient Discussions provides some power-user features that DiscussionTools probably won't end up offering, like the ability to move discussions between talk pages. – Minh Nguyễn ^💬 06:55, 15 September 2021 (UTC)

Yes, this would be great! This tool is of such use on the Wikimedia wikis! Lectrician1 (talk) 22:53, 15 September 2021 (UTC)

Sounds like a good idea to me. I've been kind of bummed the other thing hasn't been implemented yet. In the meantime being able to move discussions between talk pages would be awesome. --Adamant1 (talk) 04:50, 16 September 2021 (UTC)

@Lectrician1 and Adamant1: Here you go: Convenient Discussions. Minh Nguyễn ^💬 09:54, 19 September 2021 (UTC)

Convenient Discussions

I also installed Convenient Discussions as a gadget. You can enable it in the Gadgets tab of the preferences page. This gadget completely overhauls the talk page experience with a more interactive interface that you can edit inline. This is intended to be a stopgap until DiscussionTools is ready to be installed here as an extension (as an alternative to Structured Discussions). However, I don't think it would be prudent to enable it by default, because it's very much the JOSM of wiki talk pages: bewildering to inexperienced users, but difficult for a power user to live without. If you enable this gadget, you don't need Comments in local time, and they probably aren't compatible with one another. Minh Nguyễn ^💬 09:53, 19 September 2021 (UTC)

@Minh Nguyen: Can you enable it by default for all users? Many will not know that this exists... Lectrician1 (talk) 21:52, 19 September 2021 (UTC)

OH WAIT. This is not used on Wikipedia. This is different. Didn't try it out before posting that lol. It's the beta features Talk pages project that has the nice discussion system. Is there a way we can add that? Lectrician1 (talk) 21:57, 19 September 2021 (UTC)

@Lectrician1: That would be mw:Extension:DiscussionTools, which is still in active development. I've been watching these updates closely and I'm eagerly waiting for it to mature a bit before we ask the sysadmins to install it. The problem with installing it now is that they may make breaking changes on the backend at any time, leaving us stranded on an experimental, unsupported version that won't be compatible with future MediaWiki versions. The extension keeps a light touch on the wiki pages themselves but does have a backend aspect to power topic subscriptions and possibly other features down the line. In the meantime, please provide the team with any feedback that you think will make DiscussionTools more useful to an external wiki such as this one. – Minh Nguyễn ^💬 23:12, 19 September 2021 (UTC)

@Minh Nguyen I just don't see why we can't install mw:Extension:BetaFeatures. If all of the Wikimedia wikis have it and it's marked as stable, why can't we? I don't get what's going to "break". Beta features are so nice. We don't have to force users to use beta features. Users could opt-in if they want. Lectrician1 (talk) 00:52, 20 September 2021 (UTC)

@Lectrician1: I agree that DiscussionTools is very nice as-is, at least from a user perspective, but that doesn't necessarily mean it's ready for a non-Wikimedia wiki that isn't monitored closely by the WMF ops team. DiscussionTools is currently rated experimental, not stable. Beta would seem like a more prudent time to install the extension. I don't know how far the talk pages project is from beta, but the Usability subproject has barely begun and could yield nontrivial backend changes to support permalinks. You're probably most eagerly awaiting the Reply tool, which has been enabled on all the Wikimedia wikis. (Less mature features like topic subscriptions have only been enabled on a few wikis so far to iron out scalability issues.) But in order for any of the features to become available to users, we'd need to install the BetaFeatures extension. The absence of BetaFeatures on this wiki has already led to VisualEditor hiding some features, so if it isn't too much of a burden on the sysadmin team, we could ask for it to be installed as a first step. – Minh Nguyễn ^💬 02:16, 21 September 2021 (UTC)

Okay, ya I understand that it's still experimental. I'd love to have BetaFeatures as requested. It's up to you and probably @Tigerfell whether to ask on operations though since you guys have much more say about the Wiki than I do. Lectrician1 (talk) 13:59, 21 September 2021 (UTC)

Resolved: I think that this discussion can be safely archived Mateusz Konieczny (talk) 08:07, 29 March 2022 (UTC)

Proposed bot edit: null edits

Some pages are not listing categories, some files are not listing their usage (resulting in problems like File talk:Google-cloud-console-select-a-project.png)

This can be solved by applying null edit on given page.

I propose to run a bot edit that would apply null edit to every single page forcing refresh of categories/file usage. This would not cause pages to be edited but should refresh their categories and listings of file use.

It is a hacky solution, but OSM Wiki is consistently mostly ignored at https://github.com/openstreetmap/operations and https://github.com/openstreetmap/chef (see for example https://github.com/openstreetmap/chef/pull/400 or https://github.com/openstreetmap/operations/issues/383 )

Or maybe we should wait for https://github.com/openstreetmap/operations/issues/599 a bit before doing this?

Asking here as (1) I would need a bot account to bypass rate limit on editing (2) I want to confirm that it is a good idea.

Mateusz Konieczny (talk) 09:26, 14 March 2022 (UTC)

Category:Pages where expansion depth is exceeded, which appears to be mostly pages where reindexing has failed, has gone back over 80,000 which suggests that there is ongoing corruption of the index. Although null edits to all 250,000 pages has the advantage of updating categories following changes to data items and page content language settings, it may be prudent not to run the bot at a fast rate. --Andrew (talk) 13:02, 14 March 2022 (UTC)

I am afraid that nothing will happen with regards to issue 599. Your proposition is definitely a non-optimal solution. I can only think of one better solution. That is joining the sysadmin team and negotiating that one takes care of the wiki installation only. (Without the negotiation, they will assign you to the operation of primary or other secondary services according to their Service classification policy.)

When I used MediaWiki's category script, I reached a speed of about 10 seconds per page, maybe even 6 seconds. Even with the 6 seconds rate, you bot would run for over 17 days non-stop. You could exclude redirects to improve performance. The categorisation of redirects faced problems even before 13 February because the re-indexing script gave them a lower priority. --Tigerfell  (Let's talk) 11:15, 15 March 2022 (UTC)

Sadly, in this case I have no idea why it is broken and how to unbreak it (if I would know how to fix it properly then I would volunteer for that) Mateusz Konieczny (talk) 13:14, 15 March 2022 (UTC)

Another idea, quite desperate: ask on OSMWeekly / mailing lists / forum / etc is anyone aware what is going on and how to fix it. Maybe also on some mediawiki discussion channels? In related news, Category:Pages where expansion depth is exceeded is exploding: now over 2000 categories and over 34 000 pages Mateusz Konieczny (talk) 13:17, 15 March 2022 (UTC)

The category has consistently declined since the bot started. If there are still pages in the category when the bot finishes you could try another bot run, this time only touching pages in the category so that the indexed ones are left alone and not corrupted. --Andrew (talk) 19:39, 15 March 2022 (UTC)

I have not run bot so far Mateusz Konieczny (talk) 03:20, 16 March 2022 (UTC)

I support it. maro21 20:47, 19 March 2022 (UTC)

Resolved: wiki fixed itself, at least for now. I may do it in future in case of a similar situation to achieve this result faster Mateusz Konieczny (talk) 10:17, 28 March 2022 (UTC)

Proposed bot edit - add uploader user names on -self suffixed templates

For example, on file uploaded by Foobar with

{{CC-BY-SA-4.0-self}}

it would be replaced with

{{CC-BY-SA-4.0-self|1=Foobar}}

making more clear what is the proper attribution

Edits would look like https://wiki.openstreetmap.org/w/index.php?title=File:Oberpfalz-Aufteilung.png&diff=2297374&oldid=2297316 Mateusz Konieczny (talk) 08:17, 24 March 2022 (UTC)

 Support, but what if license template was added by you or me? Does the bot read the file uploader or the page editor? --Chris2map (talk) 20:23, 24 March 2022 (UTC)

Uploader Mateusz Konieczny (talk) 20:57, 24 March 2022 (UTC)

Does {CC-BY-SA-4.0-self|1=Foobar} mean that Foobar is the author of the image? maro21 22:01, 24 March 2022 (UTC)

Yes, or at least it should be used in such case Mateusz Konieczny (talk) 22:14, 24 March 2022 (UTC)

Example edit made in the test run: https://wiki.openstreetmap.org/wiki/?diff=2304837&oldid=2278057 Mateusz Konieczny (talk) 15:08, 29 March 2022 (UTC)

Resolved: I will be slowly starting edits (no idea how many pages are affected) Mateusz Konieczny (talk) 11:59, 30 March 2022 (UTC)

Categories are emptied

Anyone else who recognized strange emptying of categories? As of about Monday 14 Feb 2022 several (or all) category pages lost many members. Was something changed in the way categories are populated? E.g.

• Category:Missing data item had hundreds of entries, now only 43.
• Or in Category:Mismatched Key or Value there was Tag:service=driveway2 for many months, now no more, and no change neither on tag page nor on data item was done.
• Or Category:DE:Beschreibungen der Schlüssel für Gruppe "Eigenschaften" was populated by all existing keys when I created it some days ago, now several keys are missing and I have to recategorize them by null edits.
• Or Category:Articles containing potentially dated statements from 2022 is missing the page Key:government although it was on at first (Template:AsOf). --Chris2map (talk) 21:24, 16 February 2022 (UTC)

My first guess was that someone changed one of the templates. Looking at Template:AsOf, I did not find anything. The technical configuration for all wikis does not show any differences during this time. WikiApiary shows that there was a huge spike in the job queue on 13 February. I would guess that the categorisation jobs were dropped then. Following a null edit, Key:government is in the category again. --Tigerfell  (Let's talk) 17:22, 17 February 2022 (UTC)

In the last days there have been numerous creations of new categories e.g. for Spanish and German key and tag descriptions. Maybe the system waved the white flagg? --Chris2map (talk) 17:34, 17 February 2022 (UTC)

Another effect is that categories, hidden by Template:Hiddencat, are no longer hidden. E.g. all the categories "Item with no description in language ..." like on Key:seamark:topmark:shape.
Except for the "AsOf" case, all other cases noticed by me are automated categorizations related to items. So the cause might be somehow related to the description box template or module. Although there are no change edits. --Chris2map (talk) 13:45, 18 February 2022 (UTC)

However rather all categories are affected, so my suspicion can't be right. Another example: Category:Media license templates is lacking some templates like JOSM- and OSM Carto screenshots. --Chris2map (talk) 09:27, 19 February 2022 (UTC)

Maybe contacting https://github.com/openstreetmap/operations would be a good idea? Mateusz Konieczny (talk) 05:58, 21 February 2022 (UTC)

Are they involved with the wiki software implementation, too? I don't know exactly which team maintains what. @Tigerfell: could you or another admin deside if or who to contact, please? -- Chris2map (talk) 12:33, 21 February 2022 (UTC)

@Chris2map: https://github.com/openstreetmap/operations/issues?q=label%3Aservice%3Awiki+ Mateusz Konieczny (talk) 17:44, 21 February 2022 (UTC)

I found https://github.com/openstreetmap/operations/issues/165#issuecomment-525040553 - some script is supposed to be run weekly so we should wait one week before reoprting, I think. Currently my example is that https://wiki.openstreetmap.org/w/index.php?title=Category:Media_without_a_license_-_without_subcategory&filefrom=Kompass.gif%0AKompass.gif#mw-category-media is not listing https://wiki.openstreetmap.org/wiki/File:Osmdbstats1.png https://wiki.openstreetmap.org/wiki/File:Osmdbstats2.png https://wiki.openstreetmap.org/wiki/File:Osmdbstats4.png Mateusz Konieczny (talk) 13:20, 22 February 2022 (UTC)

OK, but the issue (Feb. 13./14.) is now older than one week, as far as I see. Let's see what next Monday brings. --Chris2map (talk) 20:05, 22 February 2022 (UTC)

• Now Tag:service=driveway2 is back in Category:Mismatched Key or Value without any changes in page history. The other cases are still open. --Chris2map (talk) 08:30, 26 February 2022 (UTC)

• Now my examples are back as expected Mateusz Konieczny (talk) 11:19, 4 March 2022 (UTC)

There are some problems with the data items categories. When I was fixing some mismatched descriptions, the number of articles in categories did not decrease and I had to wait sometimes several months for them to refresh. So I gave up with fixing these issues if I have to wait two months to refresh files in categories. I see there's an even bigger problem with them now. maro21 21:28, 26 February 2022 (UTC)

Updating data items is not causing articles to update, null edits are required. If you want I can share automatically generated list (still, needed to be regenerated - but months of wait time or null edits are not required) Mateusz Konieczny (talk) 11:57, 27 February 2022 (UTC)

Yes, I know, but when correcting a dozen or more articles I can't do null edits every time. Categories should automatically refresh more frequently, such as once a week. maro21 13:03, 27 February 2022 (UTC)

Editing a widely used template such as {{langcode}} or {{languages}} will reindex every page that references it but you have to take care not to mess things up. --Andrew (talk) 13:31, 27 February 2022 (UTC)

Not only strange emptying, but also strange filling: I found Category:Disabled with 479 pages in it - where does it come from?? Really strange. maro21 23:45, 3 March 2022 (UTC)

Null edits are fixing it. Maybe I should run bot edit that would make empty null edits to refresh them? Mateusz Konieczny (talk) 11:12, 4 March 2022 (UTC)

Bot making null edits in that category is running Mateusz Konieczny (talk) 11:17, 4 March 2022 (UTC)

This doesn't answer my question. I was just curious where they come from. Someone edited some template, added Category:Disabled and then removed it as a joke? Some pages haven't been edited for years. This category has suddenly appeared recently in Special:Wanted Categories. maro21 18:02, 5 March 2022 (UTC)

@Tigerfell: Is it still happening? Maybe I should just apply null edit on every single wiki page? 10:55, 6 March 2022 (UTC)

Conversely, Category:Pages where expansion depth is exceeded is massively overfilled. It may contain the pages that are missing from other categories. --Andrew (talk) 21:35, 7 March 2022 (UTC)

@Tigerfell: Possibly related: if we move template:languages/sandbox/doc to template:languages/doc now that Minh Nguyen’s version has been used for years and update the documentation link in template:languages, a lot of pages will be reindexed. --Andrew (talk) 21:56, 7 March 2022 (UTC)

Reported at https://github.com/openstreetmap/operations/issues/165#issuecomment-1061237138. --Tigerfell  (Let's talk) 23:15, 7 March 2022 (UTC)

2nd try: https://github.com/openstreetmap/operations/issues/599 --Tigerfell  (Let's talk) 21:39, 12 March 2022 (UTC)

The What links here index has pages missing, for instance Special:whatLinksHere/Template:Fa doesn’t include Category:Fa:Contribute. Also editing low-level templates doesn’t do its normal mass reindexing. --Andrew (talk) 12:51, 13 March 2022 (UTC)

@Chris2map, Tigerfell, and Maro21: Category:Pages where expansion depth is exceeded now only contains templates. Are the categories full as you’d expect? --Andrew (talk) 17:17, 26 March 2022 (UTC)

I can't find anything out of the ordinary for me at the moment. --Chris2map (talk) 18:13, 26 March 2022 (UTC)

I don't even know what "expansion depth is exceeded" is ;). So it's not a question for me :). maro21 19:38, 26 March 2022 (UTC)

Looks okay. I do not know why templates such as Template:BrowseWay are categorised into Pages where expansion depth is exceeded however. --Tigerfell  (Let's talk) 14:33, 27 March 2022 (UTC)

Seems to me like {{Navbox}} used by {{Element templates}} in BrowseWay/doc causes quiet a bit of expansion depth. But I think we shouldn't care. --Chris2map (talk) 18:07, 27 March 2022 (UTC)

Resolved: appears to be fixed, at least for now Mateusz Konieczny (talk) 10:20, 28 March 2022 (UTC)

Empty Polish talk pages

I went to https://wiki.openstreetmap.org/wiki/Special:PrefixIndex?prefix=Pl%3A&namespace=1&hideredirects=1 to see if there were any unresolved discussions or open questions on the Polish talk pages. What I saw was a list of blank pages without any content. What's more, the English versions of these discussions have links to these blank pages in Polish... They don't add any value. Could I remove these empty talk pages? It would help to find pages that actually have content. maro21 16:00, 20 March 2022 (UTC)

@Władysław Komorek: as creator Mateusz Konieczny (talk) 16:20, 20 March 2022 (UTC)

Do it. --Władysław Komorek (talk) 12:21, 28 March 2022 (UTC)

Change the appearance of the message on MediaWiki:Sharedupload-desc-here

Hello to all,

I would like to change the layout of the page MediaWiki:Sharedupload-desc-here,

Before	After
This file is from $1 and may be used by other projects. The description on its [$2 file description page] there is shown below.	Access to the file on Commons This file and its description are from Wikimedia Commons.

What do you think about it? Thanks in advance — Koreller (talk) 17:45, 10 March 2022 (UTC)

Looks good. Where is it used? --Chris2map (talk) 18:36, 10 March 2022 (UTC)

It's used here MediaWiki:Sharedupload-desc-here and under a lot of File in the wiki, exemple File:Maps.me_android_screenshot_2015-10.png — Koreller (talk) 19:03, 10 March 2022 (UTC)

I don't know if that might be a problem: The existing text is not only limited to files from Commons, but neutral and so could be used for embedding files from other wikis than Commons. --Chris2map (talk) 19:29, 10 March 2022 (UTC)

I thought there were only links to Commons images... @Mateusz Konieczny:, are there any external photos that are not from Commons? — Koreller (talk) 21:20, 10 March 2022 (UTC)

AFAIK no, and I am not really expecting it to change Mateusz Konieczny (talk) 21:41, 10 March 2022 (UTC)

so @Chris2map: I think there is no problem to make the change in this case? — Koreller (talk) 17:04, 11 March 2022 (UTC)

I think so, too. But I can't estimate the probability of other integrations coming. In case of changing the text layout: Do you also consider the translations? E.g. /fr, /de, ...? --Chris2map (talk) 17:18, 11 March 2022 (UTC)

The new formatting does not prevent this kind of improvement at all ! — Koreller (talk) 17:20, 11 March 2022 (UTC)

OK, I didn't mean to say that either. I wanted to comment so that the translations are not forgotten. I think it would be good if these were also adjusted at the same time. --Chris2map (talk) 18:15, 11 March 2022 (UTC)

IMHO, I think it is a bit overkill. Looking at File:Maps.me_android_screenshot_2015-10.png, there are already three sections with boxed/tabular layout. Why do we need to place even more fancy formatted sections on pages like that? --Tigerfell  (Let's talk) 22:23, 11 March 2022 (UTC)

My redesign process has several objectives:

• To allow an easier and faster access to the source
• Allow a better understanding that the file is not hosted on the OSM Wiki but on Commons
• Have a more ergonomic design in general

I think my modification is really useful and will make the life of the users of this wiki easier — Koreller (talk) 08:15, 12 March 2022 (UTC)

Are you sure that "Wikimedia Commons" is the only value that the $1 argument can take? Why $2 is removed? I also support what Tigerfell wrote. For me the current message is more readable. The button to Wikimedia Commons file is at the very top of the page, which is the most visible place. maro21 13:03, 13 March 2022 (UTC)

Unfortunately, no I'm not sure. Do you know if anyone on this wiki has a definite answer to this question of "do the external files come exclusively from Commons"? If so what is the nickname? The $2 is not deleted but embedded in the button leading to Commons.

I think your point about "placing the button to the most visible place" is very relevant, but it should not take precedence over the most important information which is the file image. So in my opinion, it should be placed after the image but before the file description.

On the other hand, indeed there is a change to be made, it is to modify the translations of this sentence, but I did not manage to find where it is done. Do you know where the translation comes from? (As it is, I would have to find where this translation is made before we can make the graphic change)

Translated with www.DeepL.com/Translator (free version) — Koreller (talk) 13:33, 13 March 2022 (UTC)

I didn't say about "placing the button to the most visible place" - the button is already there. If a file is from Wikimedia Commons, there is a button "View on Wikimedia Commons" at the top. maro21 13:56, 13 March 2022 (UTC)

Translations are at MediaWiki:Sharedupload-desc-here/ar, MediaWiki:Sharedupload-desc-here/fr etc. maro21 13:56, 13 March 2022 (UTC)

Ah thank you I had not seen! And thank you for the translations links, it would be necessary once the page in English changed to make the modification for each language — Koreller (talk) 14:59, 13 March 2022 (UTC)

Backlog among images in Labelled for deletion

Images waiting for processing in Category:Labelled for deletion are growing. For example this obvious case is waiting since December 2021.

For start: I am thankful to people dealing with this and handling deletions.

Is there some way how it can be handled better by people requesting deletions?

Separate subcategories based on why deletion is requested (separate categories for useless ones / duplicates / unfixable copyright violation / duplicate + fixable copyright violation but requiring wasting effort on that)? Just wait longer and accept that images will be not deleted for months? Help to find someone new who would be viable moderator?

I am one of main people directly responsible for that backlog as result of going through several thousand images and nominating some for deletion. (Indirectly: lack of real oversight over what is uploaded over years, result in large amount of images processed right now and likely also growing amount after six month in #Designing policy for handling files without clear license will be reached.)

So if I can do something better and allow easier processing of this images - please let me know Mateusz Konieczny (talk) 22:45, 11 March 2022 (UTC)

Sorry for being very direct but there is something you could do better IMHO. You could reply more quickly on comments regarding the deletion. I commented on the deletion of the case above on 31 January. ;-) Additionally, the wiki categorisation does not work reliably since 13 February 2022. This also effects this category.

I usually review most of the requests on the last weekend of each month. I used to do that more often, but it did not turn out to be effective.

I noted on Category:Labelled for deletion how I judge deletion requests with respect to the arguments of other administrators. When establishing Wiki:Rejected deletion policy I managed to reach some sort of consensus about the length of time before something can get deleted. It was 31 days and longer if there was a discussion previously in which one person objected the deletion. Consequently, a case might have to wait 61 days until I review the delete request. Additionally, I usually do not delete pages with a discussion that I was involved in (if it is not about formalities). As a result, Proposed features/Xian remains unresolved until someone else decides on the case (ironically, it was Mateusz Konieczny who objected my deletion request :-D).

If you want to speed up the process you could establish some sort of "simple cases" category and propose rules about what qualifies for a simpler case that can be solved more quickly. Given the negative response of my proposition, I doubt that it will be successful but maybe times have changed ....

Just commenting on the top items in https://wiki.openstreetmap.org/w/api.php?action=query&list=categorymembers&cmtitle=Category%3ALabelled+for+deletion&cmsort=timestamp&cmprop=timestamp%7Ctitle&cmlimit=50:

DE:HowTo minutely hstore

The user only requested deletion of the German translation but neither the English nor the Italian pages. Was that intended? Before the deletion request, the page looked similar to the other versions. There are many incoming links, some should be fixed.

Creating a local OSM server under FreeBSD

The same user requested deletion of the English version but not for the Russian translation. Has FreeBSD actually changed that much?

Template:Ka:Map Features:amenity

Ka:Map Features uses the template. Previously, the template was replaced with the deletion request. That meant that the pages transcluding the template had deletion requests on them, too. I fixed <noinclude> first. I think there used to be more than one, I updated the other pages, but apparently forgot this occasion.

I hope this helps. --Tigerfell  (Let's talk) 20:22, 12 March 2022 (UTC)

Thanks for a response! I did some things that may unblock some of deletions (pinged person who requested deletion of DE:HowTo minutely hstore, finally responded to the missed message in this file, withdrawn objection to Proposed features/Xian deletion). In general I have not considered that deletion may be stuck on text pages as I recently focused on files. I hope that there no other files stuck in similar way. I will also try to handle some other issues you raised, but I hope that images in general should be easier to process than some long-standing article pages Mateusz Konieczny (talk) 21:53, 12 March 2022 (UTC)

BTW, if you run into such cases where you refuse to delete and post in discussion - maybe switch {{Delete}} to {{Delete proposal}} would be a good idea? I sometimes look through {{Delete proposal}} to fix raised issues such as delinking and/or withdraw deletions that seem to be a poor idea Mateusz Konieczny (talk) 21:53, 12 March 2022 (UTC)

I think the way it is now is fine. No need to hurry. Tigerfell usually removes pages 30-40 days after reporting - that's not long. But for the reason that we don't have procedures for deleting pages, like on Wikipedia, it's that time when others can question the deletion (e.g. people watching the page). maro21 13:06, 13 March 2022 (UTC)

DBQueryError

I encountered this bug while trying to update this page:

[54ee259848babdd9bc96ecb4] 2022-03-17 02:54:59: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

I wonder if that was triggered by this edit or something else and how that can be resolved? -Ianlopez1115 (talk) 04:07, 17 March 2022 (UTC)

This could be related to [[2]]. --Andrew (talk) 07:04, 17 March 2022 (UTC)

The same error is also encountered when trying to create Tagalog version pages of certain articles with the ValueDescription and/or Translated templates. If said templates aren't added to the translated page (as in the case of this version of Tl:Tag:fast food=cafeteria), then no such errors are encountered and edits can be previewed and/or saved. -Ianlopez1115 (talk) 09:06, 17 March 2022 (UTC)

Your edit to {{Translated}} expands to {{#language:{{{srclang|en}}}|tl}}, which crashes this wiki and expands to language names in English on English Wikipedia; try replacing it with alternative text. This same flakiness affects {{ValueDescription}}; however, adding a full set of strings to {{DescriptionLang}}, {{ElementUsageLang}} and {{StatusLang}} may fix the problem for you. --Andrew (talk) 20:44, 17 March 2022 (UTC)

If that's the case, have reverted my previous edit in the {{Translated}} template and see if that solves the problem for now. Despite edits to {{DescriptionLang}}, {{ElementUsageLang}} and {{StatusLang}}, errors in the {{ValueDescription}} tag still persist and I'll revert them once this is posted.

Additionally, categories with the Tl: prefix are also hit with the same bug and encountered the same while trying to put a delete template on an inadvertently created redirect (TL:Limitations on mapping private information). -Ianlopez1115 (talk) 13:48, 18 March 2022 (UTC)

@Minh Nguyen:@Tigerfell: In addition to the previously reported crash with #language there is a failure in {{LangSwitch}} inside the Lua code. This code was copied directly from Wikimedia Commons; commons:Module:LangSwitch has needed no bugfixes since although it’s gained extra features, I believe our Mediawiki installation is probably misconfigured. To my knowledge no other language with any content in this wiki is affected, although pages in Marathi would have the same problem. It appears that this can be worked round by adding explicit output strings in Tagalog (tl=) to {{LangSwitch}} calls. This would be the ones in {{TranslateThis}} (not using {{Languagename|{{#if:{{{lang|}}}|{{{lang|}}}|{{{2|}}}}}|tl}} because it expands to #language) and possibly others for ValueDescription; the categories need a string added to {{Localised-colon}}. However the most robust solution is to fix the misconfiguration at source. --Andrew (talk) 17:49, 18 March 2022 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Ianlopez1115 and Wynndale: Thanks for narrowing it down to Tagalog. I opened this operations issue to track debugging this issue more thoroughly. I have a hunch that it's related to phab:T251850. – Minh Nguyễn ^💬 22:01, 19 March 2022 (UTC)

@Ianlopez1115: I have managed to get the categories to display by setting the page content language (in the page information) to Cebuano (ceb) overriding the prefix for the {{See also}} template. (Unfortunately this also changes the “See also” text. This trick works for any language except English.) I have also got the description box to work by setting the language explicitly, which we don’t usually do. --Andrew (talk) 20:42, 24 March 2022 (UTC)

@Ianlopez1115, Minh Nguyen, and Tigerfell: This issue now appears to be fixed. --Andrew (talk) 20:00, 14 April 2022 (UTC)

Glad to know that this issue has been resolved, hopefully for good. -Ianlopez1115 (talk) 04:50, 15 April 2022 (UTC)

CC-BY licenses without attribution: notify uploaders

Yes, I am proposing one more bot edit.

There are many images which are using CC-BY licenses (including CC-BY-SA of various versions and so on).

Sadly, large part of them is not specifying who should be attributed. For example https://wiki.openstreetmap.org/wiki/File:Sushi_k.jpg - who should be attributed as author?

Note that "lets credit uploader" is not always correct, I encountered some obvious ones where someone took CC-BY file, remembered to note license and then immediately violated its rules by skipping attribution.

I propose to

• post messages on talk pages asking to fill this info
• mark images as problematic

Note that there are cases where instead of

{{CC-BY-SA-2.0|1=name of whoever should be credited}}

freeform text is used

wykonane przez Foobar {{CC-BY-SA-2.0}}

I will try to skip such cases and review ones containing words "author" or "created" or "made" manually (or post list here asking for help), but some will receive notification asking to fill author properly

Mateusz Konieczny (talk) 11:23, 25 March 2022 (UTC)

I created https://wiki.openstreetmap.org/wiki/Template:Proper_attribution_missing that I plant to use for that purpose (putting it on pages where author was notified, similarly to {{Unknown}}) Mateusz Konieczny (talk) 08:20, 29 March 2022 (UTC)

Wiki:Requests for administrator attention

I've recently created Wiki:Requests for administrator attention because there was no such place on the Wiki where on could write such requests. So instead of writing on admins' talk pages or posting on talk pages where requests may go unnoticed, there is one place for it now. I suggests all admins to add it to the watchlist :). @Harry Wood, Lyx, Minh Nguyen, Pigsonthewing, Reneman, SomeoneElse, and Tigerfell: maro21 13:52, 2 April 2022 (UTC)

There was Category:Edit requests but it was not used very often. Some comments about the page

• As one can see from Special:ListGroupRights#sysop, admins/sysops cannot create properties, only Data administrators can.
• Shouldn't we archive the requests?
• I think it would be useful if this page were linked from any "wiki management page" like Wiki.

--Tigerfell  (Let's talk) 09:56, 3 April 2022 (UTC)

1 - Yes, I know that but I decided that I can include data administrators as well (a user doesn't need to know the difference). So I will change the text on the page and add "administrators or data administrators". We could also make a separate page "Wiki:Requests for data administrator attention", but there probably won't be many requests to create Properties. Another thing is that we have only one data administrator and he is inactive...

2 - I don't know, should we? I'm open to suggestions.

3 - Yes, I realized that today. I've been looking for places, but I don't know where to link it. One place could be the top of this page? maro21 10:17, 3 April 2022 (UTC)

1. Let's just see what happens.
2. When users use Special:PermanentLink we do not necessarily need archives to reference requests.
3. This page might be helpful or Wiki itself. I also thought of a navigation system as in Template:Good practice but I did not find a conclusive theme among the "wiki:" prefixed pages.

--Tigerfell  (Let's talk) 20:39, 3 April 2022 (UTC)

I don't understand the second point. How can I use it to archive requests? maro21 19:29, 5 April 2022 (UTC)

With it there is no need to extra archive it. Use e.g. like Mateusz has done on MediaWiki_talk:Lang#Howto. Copy the link "Permanent link" ("Link do tej wersji") in main menu on the left when you are at Wiki:Requests for administrator attention --Chris2map (talk) 20:06, 5 April 2022 (UTC)

Ok, now I get it how we can use permalink. See [3]. So in case anyone ever doubts why Tigerfell added this translation, there is a link. maro21 21:25, 8 April 2022 (UTC)

@Tigerfell: Archives are more discoverable (searchable) than arbitrary revision IDs. It could turn out to be relevant if a particular request is declined with some substantive discussion. – Minh Nguyễn ^💬 01:48, 5 April 2022 (UTC)

@Maro21: Thanks for setting up this page. Hopefully centralization will help us keep track of these requests, though the work will probably still fall on the same administrators who already keep a close eye on Category:Edit requests (not everyone does). – Minh Nguyễn ^💬 02:11, 5 April 2022 (UTC)

I have one thought to add: I think it would be good not to have discussions on the page Wiki:Requests for administrator attention, but to always have discussions on the individual article or topic pages, or on general ones here on Talk:Wiki. --Chris2map (talk) 19:18, 6 April 2022 (UTC)

Special:pages to search and edit data items are missing

Recently I can no longer find the special pages for the data items, e.g. Special:ItemByTitle/wiki/. Is that the case with you too? Does somebody has any idea? --Chris2map (talk) 20:49, 26 April 2022 (UTC)

MediaWiki was updated from 1.35 to 1.37 and now something is wrong with Data items. {{KeyDescription}} shows "The OSM wiki is experiencing technical difficulties. Infoboxes will be restored soon." --Tigerfell  (Let's talk) 21:20, 26 April 2022 (UTC)

Seems like an issue with WikiBase extension - see LUA error message on Template:Description. --Chris2map (talk) 22:02, 26 April 2022 (UTC)

WikiBase extension disabled temporarily - no access to data items

As result of a MediaWiki update WikiBase extension had to be disabled. For now there is no access to data items. That affects displaying of the tag description infoboxes.

Issue status: https://github.com/openstreetmap/operations/issues/611

--Chris2map (talk) 22:19, 26 April 2022 (UTC)

Would it be possible to enable infoboxes not relying on data items but only on OSM Wiki? Mateusz Konieczny (talk) 05:04, 27 April 2022 (UTC)

Given your recent comment there would be a clear conflict of interest doing so. --Andrew (talk) 07:36, 27 April 2022 (UTC)

There is no conflict of interest here at all. Having an opinion and having a conflict of interest is not the same. I consider data items as a bad idea - and small part of reason for that is that they introduce increased complexity of software more likely to break Mateusz Konieczny (talk) 16:46, 27 April 2022 (UTC)

Resolved: WikiBase is back alive! A huge thanks to tomhughes and nyurik! --Chris2map (talk) 06:15, 29 April 2022 (UTC)

Add Translate Extension

Bringing up this archived discussion again.

Translate Extension

Reasons

• Direct and up-to date translation will be much easier than the current state.
• Differences and amount translated of each page in each language is tracked.

How to use

• Configuring pages to be translated is easy.
• <translate></translate> tags only need to surround headers, sections of text, and other special formats.
• The <!--T:1--> tags are auto-generated and do not need to be placed. Only the <translate></translate> tags do.

Migrating

I am personally willing to take the time to convert as many pages as possible to be translated if this is implemented.

--Lectrician1 (talk) 23:40, 13 February 2021 (UTC)

• I am against adding this extension. It won't help anything and will only cause more problems. Besides, pages in other languages don't have to be an exact reflection 1:1 of English pages, they just shouldn't contradict. maro21 11:52, 14 February 2021 (UTC)
  • I don't think there are that many good reasons for page in different languages to significantly depart from each other. So in my opinion, it would be very valuable to have software support for translations and to keep track of untranslated/outdated sections. But unfortunately, it seems there has been no progress on the objections from the last time this extension was discussed: The large amount of special markup that would have to be added to the English text. Auto-generation doesn't help much because these tags will still burden every future editor of the English page. This is especially frustrating as it would seem easy enough to just use section headings to split the page for translation – larger restructuring of the page will almost always necessitate an overhaul of translations anyway. --Tordanik 13:19, 14 February 2021 (UTC)
    • No page needs to be "restructured". The <translate></translate> tags are simply added and you're good to go.
      Yes, the auto-generated <!--T:1--> tags can get in the way and might confuse new editors, but editors are warned when they edit a page with a message at the top of the editor that they need to use translate syntax. This message also links to tutorials that I find are very-detailed and easy-to-understand.
      Also, not-using or removing any translate-associated tags doesn't break anything. You just have to make sure every open tag is closed with a closed one (the editor will display an error if there isn't).
      If a new editor makes an addition to a page (such as a new section or paragraph) and forgets to put new translate tags around it, then the Translate extension will simply not show that it needs to be translated or show a longer section in-need-of-translating with the added text rather than the shorter, paragraph-oriented ones. Experienced editors who watch the page will likely fix this so that the translation is present and in the correct syntax.
      --Lectrician1 (talk) 17:41, 14 February 2021 (UTC)
  • It will help everything. There are so many pages that have not been kept up to date and can/should be translated. Pages should be a 1:1 translation. If OSM is a global project, shouldn't we provide the access to all resources in all languages that is up-to-date and consistent so that we don't run into mapping-convention divisions? --Lectrician1 (talk) 17:41, 14 February 2021 (UTC)
• What is the supposed benefit of this extra code littering page text? Is it compatible with visual editor? Is it mandating that content on each page is the same? Where is its repository and its issue tracker (AKA "is it maintained or abandoned and bitrotting")? Mateusz Konieczny (talk) 07:56, 17 February 2021 (UTC)
  • Mateusz Konieczny: The extra code is used to keep track of the parts to translate. It uses a separate interface for translation that is source-code only for now (see w:phab:T55974). It is maintained and used by the WMF itself on a lot of MediaWiki, meta, and Commons docs, and the bugtracker link is something you can click the links to find out. It does partially mandate commonness, but you can: (a) cheat the system and put something else in, or (b) transclude parts of the translated page in a more flexible article.--Artoria2e5 (talk) 05:54, 20 February 2021 (UTC)
• I am very much in favor of this thing, as it would represent a pretty big improvement from what we have right now. I do have a bit of an issue with the "marks the page for translation" process, since it often induces delays in updating back on WMF sites. I recommend opening up this position for application by autoconfirmed users so that more people can do the job. --Artoria2e5 (talk) 05:58, 20 February 2021 (UTC)
• @Lectrician1: - have you tested how this extension interacts with all subsets of extensions that you also proposed? And with current OSM Wiki install? Mateusz Konieczny (talk) 10:44, 23 February 2021 (UTC)
  • @Mateusz Konieczny: Okay so this extension and its implementation is another reason why I need to setup my own instance of MediaWiki. Like Artoria2e5 said, administrators/people with permissions are needed to indicate if a page should be translated. That means if the Translate extension were to be implemented on this Wiki today, we wouldn't really be able to translate any of the pages with out an admin checking through each of the pages and marking them for translation. There are also other things I have to test.
    I am also going to make a tutorial video on how to set up a page for translation the formatting, actually translating etc. so that people on this Wiki knows how it works before implementing it. The tutorial video on MediWiki is too old and long so I think I'll also make the video to replace that one too.
    I don't have a lot of time right now though, so it might be another 1 or 2 weeks before I can get to this.
    --Lectrician1 (talk) 16:27, 23 February 2021 (UTC)

@Tigerfell or anyone else: Are there any further comments on the Add Translate extension to Wiki proposal? I think I have covered everything previously asked on the Discussion page. How should I go about achieving community consensus? Should I post an RFC for it on the osmtalk mailing list? Lectrician1 (talk) 18:33, 20 March 2022 (UTC)

I would proceed as in the proposal process i. e. creating a voting section on that page and sending out an e-mail to the mailing list but use talk@ instead of tagging@. Regarding the policy that only wiki admins should propose new installations to the system administrators, I would say that if the proposal is accepted, I will propose the extension's installation to them. --Tigerfell  (Let's talk) 21:41, 22 March 2022 (UTC)

Short Tutorial 1: How to make a page translatable and translate a page --Lectrician1 (talk) 02:57, 28 February 2021 (UTC)

Short Tutorial 2: How to change the translatable page and re-mark it for translation --Lectrician1 (talk) 03:58, 28 February 2021 (UTC)

I would like to reintroduce proposing and implementing this.

@Maro21: Are you still against implementing this, even after the basic instructions I gave on how to use this extension in the videos above?

@Dcapillae: I know that you consitently update EN -> ES translations on Proposal process (thank you!) Would you and others in the Spanish translation community be interested in this extension? It could make translating much easier!

--Lectrician1 (talk) 19:30, 7 July 2021 (UTC)

Yes, I am against. I know how the extension works, because I use it on Translatewiki. It's good to use it for short messages, but not for long articles. Everyone would translate 1/100 of the page and it will be a mess. Do you translate articles to other languages? I do and I prefer to press edit and write the whole article and this extension won't make translating easier, but harder. I also think that article translations into other languages don't have to be 100 percent identical. I often write articles in Polish and sometimes I add more than there is in English. maro21 21:09, 7 July 2021 (UTC)

Hi! Thank you for the video tutorials. I have never used the extension before. Watching the videos, it looks really convenient and easy to use. Maybe it would encourage more users to collaborate with translating. I don't really have a strong opinion on whether it is a good idea to add the extension or not. Many pages on the wiki include templates and tables. If it works properly on those pages too and doesn't give problems, any improvement is welcome. Regarding the Spanish translators community, I think nobody will be against it. We will adapt to any wiki improvements. --Dcapillae (talk) 22:36, 7 July 2021 (UTC)

@Tigerfell: How can we make progress so that this proposal can fully be considered and possibly implemented by the community? Should a formal proposal page be made? Should a discussion be started on the talk mailing list? --Lectrician1 (talk) 01:45, 9 July 2021 (UTC)

I suggest you first contact Firefishy (on osm, edits, contrib, heatmap, chngset com.) and ask him whether there was a technical reason for not installing the extension in the past. The chef configuration controls five wiki instances with different extensions. The sysadmins and I once tried to install w:mw:Extension:Maps. It required Composer, which did not work well with the configuration back then. --Tigerfell  (Let's talk) 15:53, 10 July 2021 (UTC)

(I'll just ask here) @Firefishy: Is this possible to install for this Wiki? --Lectrician1 (talk) 18:58, 10 July 2021 (UTC)

Okay, well User:Firefishy never responded even after emailing them, so I went ahead and created a full proposal page where the entire system and implementation is documented.

The plan is probably to release it to the talk mailing list in 2 days and then maybe 2 weeks later start a vote.

Let me know if I've missed anything and feel free to contribute.

Proposal: Proposed features/Add Translate extension to Wiki

--Lectrician1 (talk) 23:53, 20 July 2021 (UTC)

@Tigerfell: Well IDK when or if openstreetmap/operations/issues/555 will be answered, but at some point, could you make a issue formally proposing the extension? --Lectrician1 (talk) 18:04, 27 July 2021 (UTC)

I would like to have a community consensus or at least a majority decision to back up a formal proposal. When I formally propose the addition of an extension or even write a  Pull request, I essentially decide the case. Nonetheless, the system administrators will check my request, too.

I will review your proposal and comment on its talk page in case I think something should be discussed before voting on the proposal. --Tigerfell  (Let's talk) 19:50, 29 July 2021 (UTC)

Is it replaced by Proposed features/Add Translate extension to Wiki? Mateusz Konieczny (talk) 10:23, 28 March 2022 (UTC)

Resolved: I notified participants in this discussion about new one. I think that this one may be safely archived Mateusz Konieczny (talk) 08:06, 29 March 2022 (UTC)

OSM Carto categories

Resolved

I'm planning to upload some screenshots of OSM Carto and I noticed that we don't have categories for such images. Currently there are:

• Category:Mapnik Rendering Examples (319 files),
• Category:Mapnik Icon (65 files),
• Category:Mapnik Icon svg (270 files),
• Category:Slippy Map (Mapnik) screenshots (11 files),
• Category:Mapnik map key images (6 files),
• some of them are in Category:Rendered OSM data
• and a lot of uncategorized files.

I think there should be categories with names starting with OSM Carto * because Mapnik is a map rendering toolkit and OSM Carto is a map style. These names are often confused. What do you think? Do you agree?

I think there should be 3 categories:

• one for icons like this one
• one for rendering examples used in infoboxes, like this one
• one for any screenshot from OSM Carto, like this one.

I will create templates, for example {{OSM Carto icon}}, {{OSM Carto example}}, {{OSM Carto screenshot}} which will add a proper license template and categories.

I will create the templates and categories, I just don't know what would be the appropiate names for these categories: Category:OSM Carto icon (or Category:OSM Carto icons?), Category:OSM Carto rendering examples, Category:OSM Carto screenshots? Are these names ok?

I can recategorize files, I'm just asking here for the names of such categories, if they're ok. Category names will only be added by the template, so they can easily be changed anyway. maro21 17:21, 15 June 2021 (UTC)

"because Mapnik is a map rendering toolkit and OSM Carto is a map style. These names are often confused. What do you think? Do you agree" +1, that is a great idea! Mateusz Konieczny (talk) 07:34, 20 June 2021 (UTC)

Template:OSM Carto example has a misleading name - not all OSM Carto examples qualify as Template:PD-shape, only the simplest ones. This name is poorly chosen and should be changed to avoid confusing people. Or just use Template:CC0 here, with Template:PD-shape added to files qualifying for it (@Maro21:) Mateusz Konieczny (talk) 07:34, 20 June 2021 (UTC)

I corrected the description because this template was only meant for simple shapes that qualify for PD-Shape. The purpose of this category and template was to be for simple shapes where there is no data from OpenStreetMap contributors. Can you give an example that does not qualify under PD shape and what license would it have? If there are such instances, this template simply won't be added there. maro21 20:14, 26 June 2021 (UTC)

---

So, since June 2021 I've been working on these files and categories. There was a lot of work. In addition to adding categories, I had to unlink the old renderings on tag pages and replace them with new ones. I also found some duplicates. I emptied following categories:

• Category:Mapnik Rendering Examples (319 files → 0)
• Category:Mapnik Icon (65 → 0)
• Category:Mapnik Icon svg (270 → 0)
• Category:Slippy Map (Mapnik) screenshots (11 → 0)
• Category:Mapnik map key images (6 → 0)

created new ones:

• +277 Category:OSM Carto icons
• +38 Category:Old OSM Carto icons
• +216 Category:OSM Carto rendering examples
• +73 Category:Old OSM Carto rendering examples
• +970 Category:OSM Carto screenshots (populated not only by me)
• +85 Category:Animated OSM Carto screenshots

and populated existing ones:

• +202 Category:Osmarender Rendering Examples (there were only a few files before)
• Category:Main OSM website (with files)
• Category:Trademarks and logos of OpenStreetMap Foundation

maro21 19:28, 3 April 2022 (UTC)

License of old OSM Carto screenshots

Resolved

Should old "Mapnik" (a name used for standard tile layer OSM Carto in the past) screenshots like this File:2010 decembris.png, made before September 12, 2012, have CC-BY-SA 2.0 license? I read https://wiki.osmfoundation.org/wiki/Licence/About_The_Licence_Change but I'm not 100% sure. Help is welcomed. maro21 20:23, 28 July 2021 (UTC)

Yes, this change is (1) unable to retroactively remove CC-BY-SA license from old ones (2) not indicating that ODBL was granted to screenshots made in the past Mateusz Konieczny (talk) 07:29, 29 July 2021 (UTC).

Thanks. I asked because I stopped during categorizing the other screenshots. I realized that they should probably have a different license. So I created an additional template similar to {{ODbL OpenStreetMap}} which contains "© OpenStreetMap contributors" + CC-BY-SA-2.0 license: {{CC-BY-SA-2.0 OpenStreetMap}}. Example usage here: File:2010 decembris.png. Is everything ok with it? maro21 18:09, 5 November 2021 (UTC)

Templates for licenses requiring credit should check for it

There are some licenses that require attribution.

But it is sometimes missing, see for example https://wiki.openstreetmap.org/wiki/File:OpenStreetMap_in_an_IC2_carriage_(DB).jpg https://wiki.openstreetmap.org/wiki/File:ETrex20.jpg https://wiki.openstreetmap.org/wiki/File:Basemap-screenshot.png https://wiki.openstreetmap.org/wiki/File:Mappertreffen_Torgau_2015.jpg https://wiki.openstreetmap.org/wiki/File:By.png https://wiki.openstreetmap.org/wiki/File:Addr-housename.JPG https://wiki.openstreetmap.org/wiki/File:Josm1.png https://wiki.openstreetmap.org/wiki/File:16052010022.JPG https://wiki.openstreetmap.org/wiki/File:Barrier1.jpg https://wiki.openstreetmap.org/wiki/File:Cc.png https://wiki.openstreetmap.org/wiki/File:Icon_gps.png https://wiki.openstreetmap.org/wiki/File:Asso.png https://wiki.openstreetmap.org/wiki/File:Data_conflation_workflow3.gif https://wiki.openstreetmap.org/wiki/File:Grenoble_-_nouveau_panneau_d%27affichage_municipal.jpg https://wiki.openstreetmap.org/wiki/File:French_sfr_ftth_id.jpg https://wiki.openstreetmap.org/wiki/File:Beyondtracks-map.png https://wiki.openstreetmap.org/wiki/File:Snowmobile_route_sign.png

In some cases uploader is author, but in some not. And it is not always certain.

I propose to replace free floating credits like

{{cc-by-2.0}} author: Foobar

by automatically checked

{{cc-by-2.0|author=Foobar}}

That would make possible to automatically detect cases where attribution is missing

Alternatively, create a separate template for author:

{{cc-by-2.0}}{{author|Foobar}}

It is better because such new template would be easier to use (non need to modify many templates), but detection of missing authorship would not be possible using categories on Wiki, but a script crawling through pages

Mateusz Konieczny (talk) 15:54, 15 January 2022 (UTC)

Hi Mateusz! Why do one have to modify templates in case of the script thing? Couldn't you script to provide e.g. {{cc-by-2.0|Foobar (Author)}} instead? --greetings, Chris2map (talk) 16:36, 15 January 2022 (UTC)

Script would be needed in case of going with {{cc-by-2.0}}{{author|Foobar}}. In case of going with demanding {{cc-by-2.0|author=Foobar}} (or {{cc-by-2.0|1=Foobar}}) no script would be needed. In either case part of the work would be on converting free floating author into something machine readable and asking uploaders to fix remaining ones Mateusz Konieczny (talk) 22:02, 15 January 2022 (UTC)

OK, I just wanted to point out that templates with cc-by already have parameter 1 for attribution. The inline variant is ok for me, also if work may be to do on license templates. - On the other hand we might yet fundamentally need an extra template to structure the process of licensing by uploaders (I have started a first draft User:Chris2map/Sandbox#Testing_Template:License_of_file). --Chris2map (talk) 10:00, 16 January 2022 (UTC)

I found {{Information}} - which would solve this problem if it would be used across files Mateusz Konieczny (talk) 07:58, 26 January 2022 (UTC)

Also found it one week ago and reused it in Template:Sandbox for a draft for License of file. --Chris2map (talk) 13:32, 29 January 2022 (UTC)

Resolved: Category:Attribution not provided in CC license template which requires attribution now exists and is populated by templates itself Mateusz Konieczny (talk) 19:58, 2 May 2022 (UTC)

Categories missing entries

Category:Media license templates seems to be missing Template:Tiles@Home screenshot

Template:Tiles@Home screenshot is marked with this category

Any idea how to fix it? Is there something missing that I do not see? Is "entries missing from categories" mystery issue making a repeat appearance? Mateusz Konieczny (talk) 06:56, 1 June 2022 (UTC)

Did null edits on /doc and then template. Now it's there. --Chris2map (talk) 15:51, 1 June 2022 (UTC)

Resolved: Thanks, the same worked for another template! Mateusz Konieczny (talk) 12:22, 2 June 2022 (UTC)

Is it OK to blank these pages?

I am trying to process Category:Image superseded by Wikimedia Commons (verify proposed replacements, migrate file use, mark files for deletion as not needed duplicates) and run into User:Simone/FotoTaggare User:Marcello/tag which are a bit fragile (files shown in full size making necessary to tweak how files are displayed). These are user subpages of inactive users.

Would it be fine to just blank them? If they return (unlikely) they would be able to simply revert such change. Or should I continue repairing/improving this pages on processing this files? Mateusz Konieczny (talk) 04:57, 10 March 2022 (UTC)

I would support your plan. I think we should avoid emptying pages, but if we get in copyright issues with old content, we need to have a practice to treet it with acceptabel time and effort. What about this: - A) If user is inactive less than 3 years, we could try to contact him and ask to help solving the issues (like licensing of images). If there is no reaction within 1 month, page will be blanked. - B) If user is inactive for 3 years or more, page can be blanked. - In all cases of blanking we should place a template which shows an info box and adds a category to inform others what was going on. --Chris2map (talk) 17:19, 10 March 2022 (UTC)

I now edited this two pages Mateusz Konieczny (talk) 11:24, 12 March 2022 (UTC)

resolved|Mateusz Konieczny (talk) 11:26, 12 March 2022 (UTC)

In my opinion, user pages should not be edited in such cases. If something else is displayed there, we should not worry about it. I am against editing users' pages unless it is necessary (e.g. removing a page from a category). maro21 12:55, 13 March 2022 (UTC)

I understand your concerns. But in case of media files such as images - those are not stored on the user page only. How to handle copyright queries? The deletion of used files always is a question. Should we override files lacking copyright information but used on user pages with place holders? --Chris2map (talk) 13:17, 13 March 2022 (UTC)

If we delete a file, we can either: 1) do nothing - leave a userpage with a broken link to a file, which is fine; 2) edit the page and fix a link: a) if there is a replacement, add a new link to the identical file; b) delete a link if there is no replacement to the deleted file. This (point 2) is good behavior but requires taking the time to edit the page. 3) blanking the whole page - I see no logical reason to blank the user subpage just becasue some files were removed. I wouldn't like someone to edit my user subpages if I'm inactive.

Such tasks - replacing files with files from Commons - would be best done by bots. maro21 14:10, 13 March 2022 (UTC)

So you would prefer to delete file despite its use at user pages, right? Mateusz Konieczny (talk) 15:15, 13 March 2022 (UTC)

Yes, I would. On the assumption that the reason for deletion will tell the user why the file was deleted. maro21 21:05, 19 March 2022 (UTC)

I would like to state my opinion in the case of File:Fast food.png. Honestly, I do not see the advantage to have such files deleted if they are still used on some discussion pages and user pages. The deletion just breaks pages. If you want to replace images, I prefer to have them replaced on all pages. Then you can still read along those pages. --Tigerfell  (Let's talk) 20:48, 13 April 2022 (UTC)

Hotcat - quick edits broken

Any idea why adding categories with HotCat drops to regular edit, making necessary to click more times for the same effect?

I added window.hotcat_no_autocommit = false in User:Mateusz Konieczny/common.js

Maybe something changed during wiki upgrade? Mateusz Konieczny (talk) 23:03, 2 May 2022 (UTC)

I updated HotCat with the most recent version from Wikimedia Commons. It works for me now again. --Tigerfell  (Let's talk) 19:30, 4 May 2022 (UTC)

Resolved: Mateusz Konieczny (talk) 20:10, 4 May 2022 (UTC)

Images on the Wiki OSM

I saw that the images in the Wiki were generally badly described. I also saw that you, @Chris2map: and especially @Mateusz Konieczny:, had done a lot of work to create license templates, then insert them on the many unlicensed images, then notify importers of images that didn't have enough details. Thanks for the hard work already done.

In this idea of improving the description of files on the wiki, I was thinking of using the description structure that exists for Commons for images on the OSM Wiki, with separate sections:

• the first for the file description (date, caption, creator)
• the second section for the license of the file

What do you think about it?

Besides, I started a User:Koreller/Images subpage to collect informations, links and useful code for this project. — Koreller (talk) 15:43, 8 May 2022 (UTC)

Thanks for your attention! I support this structure. (Once I wanted to do that too Template:Sandbox&oldid=2266718). I see, Tigerfell is already diligent and working on it: Special:Upload, MediaWiki:Upload-default-description. --Chris2map (talk) 16:39, 8 May 2022 (UTC)

Which exact images are badly described? It depends only on the uploader how much information they give about the uploaded file. The biggest problem is not giving the license and author or source. Although we've put a lot of work into adding licenses to the existing files, unfortunately most new files not uploaded by active Wiki users don't have licenses.

Koreller, please don't add the template just for the sake of adding the template. Don't add false authors for OSM maps. The authors of OSM maps are OpenStreetMap contributors. Uploader ≠ author. Please don't duplicate section "License", it is added by some templates so please check before saving changes. I've already categorised all OSM Carto screenshots, you don't have to do that again. I personally don't like copying something from somewhere just because it is somewhere. Wikimedia Commons is different than OSM Wiki. Using {information} template can be good for new files, but not for duplicating information which is already there, in the upload log. So I'm not a fan of adding a template and duplicating information that is in the upload log:

• description - it was or it was not added by the uploader
• date - the date of a photo is known usually only by the uploader (if so) unless it's hidden in the metadata. Here you added the date 2022-05-07, but the satelite image from Bing wasn't taken this week.
• author - if not explicitly stated, the author is usually known only by the uploader and uploader ≠ author
• permission - for licenses we have separate templates and section. Duplicating information which is already in the License section would be bad. example

Adding the date to the description of a file that is a map is not a good idea, because these are often overwritten with new versions and the old date remains in the description when someone uploads a new version. It could be good for photos, telling when the photo was taken. However, the date of upload doesn't equal the date the photo was taken. And this is actually the case for all files. maro21 23:45, 8 May 2022 (UTC)

Template itself looks quite well, thanks for improving it. But you made multiple edits without distinguishing uploader of image and author. If I take copyrighted photo and upload it then I am not becoming its author. Mateusz Konieczny (talk) 08:47, 9 May 2022 (UTC)

• https://wiki.openstreetmap.org/wiki/File:Mapnik_motorway_junction.png
• https://wiki.openstreetmap.org/wiki/File:EST_mapnik.png
• https://wiki.openstreetmap.org/wiki/File:Maidstone.jpg
• https://wiki.openstreetmap.org/wiki/File:Skeifan-2008-08-20.png
• https://wiki.openstreetmap.org/wiki/File:Skeifan-2008-09-28.png
• https://wiki.openstreetmap.org/wiki/File:Zellerau_19.09.2008.png
• https://wiki.openstreetmap.org/wiki/File:Zellerau_23.08.2008.png
• Why you put this author info? It seems wrong, it looks like OSM data to me. Uploader was stated as sole author what seems clearly wrong, if they would be mentioned at all then it should be clear that they just took screenshot (unless they also mapped large part of depicted data and/or made style then this role can be also mentioned). Please fix this author info and also for other images you modified. Mateusz Konieczny (talk) 08:41, 9 May 2022 (UTC)

https://wiki.openstreetmap.org/wiki/File:Firebrigade.png - how do you know that Krasnoj is image author, not just uploader? (@Koreller:) Mateusz Konieczny (talk) 08:41, 9 May 2022 (UTC)

I would recommend to take time and discuss and coordinate those things first, bevor we get started overall. It is good that now we already have example structure on upload page for new ones. @Koreller: I think most simple would be if you could revert your recent edits on the files (except for clear cases). So we could focussing on general how to instead of discussing each edit or file. --Chris2map (talk) 21:19, 9 May 2022 (UTC)

Hi @Chris2map I saw that you change the structure on upload page, thank for this ! I also remarkt that the section name could be improve, do think it's possible to use the code :

• == {{int:filedesc}} == instead of == Summary ==
• == {{int:license-header}} == instead of == Licensing ==

and add a line break between those two section ? — Koreller (talk) 19:37, 2 June 2022 (UTC)

@Chris2map:, @Mateusz Konieczny: For the images you can make the revert I had to disorganize some files, there is no problem — Koreller (talk) 16:00, 16 May 2022 (UTC)

Resolved: Mentioned image edits were reverted. File upload dialog has been updated to use {{Information}} with new uploads. --Chris2map (talk) 20:32, 27 June 2022 (UTC)

requesting images for wiki

(and elsewhere)
Where online is a good place to request images of a place? (my example location is that described at talk:Torino). Arlo James Barnes (talk) 02:12, 8 June 2022 (UTC)

(1) search on Wikimedia Commons for images (2) search on more local projects with free images (for example Geograph in UK) (3) search on Flickr for openly licensed images (3) contact local community (see local channels) (4) check Mapillary (5) take own photos Mateusz Konieczny (talk) 10:04, 8 June 2022 (UTC)

Resolved: answered, no idea where on OSM Wiki this info can be added so not added it anywhere Mateusz Konieczny (talk) 12:04, 27 June 2022 (UTC)

Special:Upload suggested licenses: add -self templates in the list

Resolved: --Tigerfell  (Let's talk) 13:05, 11 June 2022 (UTC)

Hello, there!

When I upload files and set the license to, say, CC-BY-SA 4.0, it adds the CC-BY-SA-4.0 template on the uploaded file page. The problem is that the author of the file is often its uploader; to ease licensing of such files, the -self version of such licensing templates, with the user name as parameter, should be added in the list of the Special:Upload page, preferably before the non -self version of the template, as uploader and author are likely to be the same person. That would greatly lower the number of upload with license but which don't specify the author or attribution as required by the license.

Regards. --Penegal (talk) 16:13, 9 June 2022 (UTC)

Hi, that's right, but (always) it would or could likely lead to some or several uploads with a "self" statement, where it is actually not true. There have to be all license variants (CC0 and CC0-self are already on), but this would end in a marathon list. I've no clever idea for now. --Chris2map (talk) 17:25, 9 June 2022 (UTC)

It would need to be clearly described - if someone is willing to lie about real source they can do it anyway Mateusz Konieczny (talk) 17:35, 9 June 2022 (UTC)

Osm Go! is looking for translators and developers

Resolved: Unrelated to the wiki. I commented on another of your posts. --Tigerfell  (Let's talk) 18:10, 17 June 2022 (UTC)

The Osm Go! team is looking for translators in any languages & developers.

• Translations are done on POEditor, just read the instructions here.
• Developers feel free to make some PR. Guidelines available here.

-- Binnette (talk) 07:56, 17 June 2022 (UTC)

Deplatforming platform status

See Talk:Main_Page#Platform_status Mateusz Konieczny (talk) 16:36, 17 June 2022 (UTC)

Resolved: people were notified Mateusz Konieczny (talk) 09:58, 24 June 2022 (UTC)

Is Template:Osm-query2 working?

I encountered Template:Osm-query and tried to migrate to Template:Osm-query2 but it also seems broken. Any idea how to get https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant#Already_used? https://wiki.openstreetmap.org/wiki/Proposed_features/Art_gallery#Already_used https://wiki.openstreetmap.org/wiki/Proposed_features/Construction#Already_used? to work? Mateusz Konieczny (talk) 21:15, 22 June 2022 (UTC)

I remember that I faced the same situation. I abandoned my work on that point because I did not understand it thoroughly enough. Looking at the examples in the documentation, I would say it is something similar to Overpass turbo. --Tigerfell  (Let's talk) 22:41, 23 June 2022 (UTC)

Have you tried following example links? For me no map worked, but I want to confirm breakage before removing (maybe someone know something about planned resurrection or can fix something?)Mateusz Konieczny (talk)

Yes, I did. This worked (no tiles obviously) map: Bahntrassenradweg Bergisch Born - Marienheide

To find out more, you could contact w:User:TheDJ. Some background: https://help.openstreetmap.org/questions/83146/contact-user-thedj-if-you-want-maintain-osmdb, https://phabricator.wikimedia.org/T187601. It seems entirely unmaintained. --Tigerfell  (Let's talk) 16:02, 24 June 2022 (UTC)

Well, I meant "and no map is displayed" as the problem making it unusable Mateusz Konieczny (talk) 09:58, 26 June 2022 (UTC)

Resolved: described as broken on its page, removed several uses by archiving proposals Mateusz Konieczny (talk) 12:02, 27 June 2022 (UTC)

Attribution

I have uploaded some images and photos, and I have selected CC-BY in the list. However, I receive a message from a bot: https://wiki.openstreetmap.org/wiki/User_talk:Angoca#Attribution indicating that I have not provided a license, which is false.

I need more details about to solve the problems.

@Angoca: - as mentioned there you need to also provide authorship info (CC-BY license requires clearly stating author). For example for https://wiki.openstreetmap.org/wiki/File:Contributors.png - are you author of that text? Mateusz Konieczny (talk) 11:03, 5 June 2022 (UTC)

"I have selected CC-BY in the list" - it is possible that it should be better designed with separate entry for "CC-BY-4.0, I am the author and copyright holder" or have a separate entry asking for who is the author of media. In general I would advise to upload files to https://commons.wikimedia.org/ where file upload and file management is better designed as result of spending monumental effort on this Mateusz Konieczny (talk) 11:03, 5 June 2022 (UTC)

This should be explicitly stated in the "Upload file" section because receiving a mail for every image I have uploaded saying that it will be deleted is very bothering. This could be considered spam for the massive mails received with a very similar subject, and just a few people will react by putting the author in the tag in each file.

It would have been better to notify previously the wiki authors that there will be a campaign the improve the tagging for files via a bot, instead of imposing to perform an action right now otherwise the files will be removed.

Also, future uploaded files will continue to have the problem because that special page has not been changed to include the right tag, so you are not really solving the issue. AngocA (talk) 15:05, 5 June 2022 (UTC)

"notify previously the wiki authors that there will be a campaign the improve the tagging for files via a bot" this edits are doing exactly this. Feel free to propose changes in the message so it will be more clear or more encouraging or better in other way. Mateusz Konieczny (talk) 15:12, 5 June 2022 (UTC)

"future uploaded files will continue to have the problem because that special page has not been changed to include the right tag" - I agree that someone(TM) should fix this problem. I would propose to encourage even stronger to upload files to Wikimedia Commons as it unlikely that we will have ability to even replicate their interface, not speaking about improving it Mateusz Konieczny (talk) 15:12, 5 June 2022 (UTC)

How can I use a Wikimedia Commons images in a OSM wiki article? Which tag should I use? I didn't find the option in the visual editor, nor in some of the OSM Wikiproject. Can you guide me in this? Do you have a wiki page example? Thank you

-- AngocA (talk) 00:53, 8 June 2022 (UTC)

"How can I use a Wikimedia Commons images in a OSM wiki article?" in exactly the same way as photo uploaded to OSM Wiki Mateusz Konieczny (talk) 10:01, 8 June 2022 (UTC)

Sorry for the confusion, but I meant how can I reference a Wikimedia image in an OSM wiki article? I have only seen the option to use internal (OSM wiki) images, but not images from external URLs. AngocA (talk) 16:28, 8 June 2022 (UTC)

in exactly the same way as photo uploaded to OSM Wiki. For example in this edit I will add https://commons.wikimedia.org/wiki/File:Turquoise_Swirls_in_the_Black_Sea.jpg named "File:Turquoise Swirls in the Black Sea.jpg":

@AngocA: Mateusz Konieczny (talk) 16:52, 8 June 2022 (UTC)

Which image you want to add? Both Visual Editor and direct edits of wikicode support both Mateusz Konieczny (talk) 16:55, 8 June 2022 (UTC)

See my page North Korea Mapping Guide, where I use Commons images and OSM Wiki Images, spoiler : you can't see the difference in the wikicode, it works the same.

Moreover, you don't need to "import" file from Commons to OSM Wiki, just call it from OSM Wiki and it will be display. — Koreller (talk) 19:24, 8 June 2022 (UTC)

Resolved: @Angoca: - please comment if you need further help Mateusz Konieczny (talk) 21:16, 22 June 2022 (UTC)

Trailing : in page titles for key prefixes

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

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

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

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

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

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

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

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

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

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

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

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

Introducing Category:Transport modes

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

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

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

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

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

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

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

Do you agree with this change?

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

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

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

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

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

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

Meta proposals

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

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

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

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

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

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

Does not involve collective use

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

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

@Sammyhawkrad: - to let you know

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

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

More category corruption

Category:Pages where expansion depth is exceeded now has 3000 pages again. A quick check suggests the pages reported there are not being listed in their categories. Andrew (talk) 20:46, 24 July 2022 (UTC)

For me this category is listed as empty Mateusz Konieczny (talk) 04:44, 27 July 2022 (UTC)

Resolved: Category:Pages where expansion depth is exceeded is empty Mateusz Konieczny (talk) 11:41, 5 August 2022 (UTC)

Followup on CAPTCHA

Resolved: Recaptcha was replaced by hcaptcha (https://github.com/openstreetmap/operations/issues/454) --Tigerfell  (Let's talk) 13:09, 3 August 2022 (UTC)

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

I'm surprised there isn't a viable open source non-commercial CAPTCHA system out there that could be adopted. When I randomly looked into it a while back it seemed like all the opensource options still sent information to some random server. Maybe there's one I'm not aware of though that could be used by the wiki. As I think any commercial one, Google or not, will probably compromise privacy somehow and therefore be semi-problematic. The only way around it would be to go with an open source one where the information sharing can be turned off or to create one just for OSM. --Adamant1 (talk) 11:52, 5 June 2020 (UTC)

I agree 100%. However the last time I came here with this question the message was that CAPTCHA is necessary and Google's will remain in use because nothing else satisfactory was suggested. That's why I suggest switching to Cloudflare's for the time being until a privacy-friendly software is found, since Cloudflare is a lesser evil than Google. Rostaman (talk) 13:10, 5 June 2020 (UTC)

See also https://github.com/openstreetmap/chef/issues/298. --Andrew (talk) 17:19, 5 June 2020 (UTC)

Google's Captcha is especially vicious because it punishes you for not having a Google account, deleting cookies or using Tor.

If you really want to defeat the SEO spam (NEW: use Cyrillic to fool the admins) you should just demand an OSM account with > 10 map edits as requirement for a Wiki account.--Tito (talk) 20:56, 5 June 2020 (UTC)

I don't think the wiki and main site are connected in way that would allow for the wiki to be able to tell if a user has 10 map edits. As far as I know, they are completely different logins etc. Not that they couldn't be integrated somehow to get around it. But a lot of higher up OSM people that should be able to edit the wiki lack map edits but are extremely active with the organization in other areas. Same for developers. So, arbitrary map edits as a qualifier could be kind of iffy. Although, 10 is a low bar, but it might be low enough for scammers to just map 10 objects then spam away. Which might slow them down but wouldn't stop them. Not that there aren't ways around CAPTCHA systems either though. --Adamant1 (talk) 04:06, 6 June 2020 (UTC)

Thanks for linking the issue @Andrew:. @others if you want to get in touch with the administrators to initiate a change, I suggest to comment on the GitHub issues. --Tigerfell  (Let's talk) 11:26, 6 June 2020 (UTC)

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

Resolved: proposal vote started at Proposed features/Namespaces for key prefixes & suffixes Mateusz Konieczny (talk) 04:45, 27 July 2022 (UTC)

The discussion started here, please read it first.

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

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

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

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

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

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

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

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

<editable list>

Words that can only be used as prefixes:

• addr, contact, drink

Words that can only be used as suffixes/infixes:

• conditional

Help finding all of them, feel free to edit.

</editable list>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Key:name template weirdness

Can someone explain where the seeAlso value of the KeyDescription template for name=* is defined? For some reason it includes links to name:ja=*, but that seems a weird place to specifically link to those so I want to remove them. I don't see any seeAlso defined in the page source though. Caching issue? --JeroenHoek (talk)

The values are pulled from the data item, see https://wiki.openstreetmap.org/wiki/Item:Q464--Kjon (talk) 16:56, 4 August 2022 (UTC)

Got it. I can't say that this level of abstraction is helpful. There is a thing called 'P18' which means 'different from', but which is queried to fill the seeAlso heading. That feels like a mismatch of definitions. I just resorted to removing those three tags from the data-item, and that fixes this issue. Not sure if that is how it is supposed to be done though. --JeroenHoek (talk) 17:04, 4 August 2022 (UTC)

Such leaks of invalid/unwanted data from data items are one of more irritating aspects of them Mateusz Konieczny (talk) 20:38, 4 August 2022 (UTC)

Not universally wanted is a far cry from unwanted. ;^)

different from (P18) has only been equated to "see also" since March. Before that, it's true that P18 statements were getting pulled under {{Description}}'s "See also" heading, but I think that's because "different than" is one of many reasons for cross-referencing another page on the wiki. I've never particularly liked stuffing a "See also" section in the infobox, because it takes away a good reason to balance out the main part of the page with a full-fledged "See also" section that explains the relationships to the other tags. Ideally, a data item administrator could build out more nuanced properties, such as incompatible with (P44), to take the pressure off a generic "see also" relationship while carrying more semantic meaning for wiki users, QA tools, and data consumers.

 – Minh Nguyễn ^💬 06:28, 5 August 2022 (UTC)

Resolved: seems solved, removal of confusing (but wanted by some) use of data items would require broader discussion Mateusz Konieczny (talk) 05:55, 28 August 2022 (UTC)

Image and JavaScript performance improvements

Firefishy just updated the wiki's configuration to improve page load performance. You should now see a marked improvement on pages that contain many images from Wikimedia Commons. Some pages that previously refused to load at all, such as MUTCD/R, will now load in a reasonable amount of time. More broadly, every page's JavaScript resources seem to be loading slightly more quickly. This should be a solid quality-of-life improvement for those who use the default "enhanced" versions of special pages, have extra gadgets installed, use the basic editor instead of VisualEditor, or edit data items. As always, if you spot a glitch that can't be chalked up to a goof-up in a template somewhere, please raise it with the administrators here or escalate the problem to the operations team. – Minh Nguyễn ^💬 06:42, 5 August 2022 (UTC)

I have also now tweeted about the site performance improvement. Sorry it took so long for me to realise there was a major problem. I will be more responsive in future due to extra available time. -- Firefishy (talk) 11:23, 5 August 2022 (UTC)

Thanks for fixing this! @Firefishy: - it seems to me that right now https://github.com/openstreetmap/operations/issues/507 is the next very important wiki issue, fixing this would make editing more accessible and threshold to contributing would be lower. What would be great Mateusz Konieczny (talk) 11:33, 5 August 2022 (UTC)

Yes, the authentication is a big ticket item that would be awesome to fix. Using some OAuth2 is the way forward. The challenges 1) osm.org "Display Names" (aka Usernames) are not fixed, we deal with this on community.osm.org by setting the name on community.osm.org on each user login and use the UserID from osm.org as the key. 2) Many usernames for wiki.osm.org do not match the same user on osm.org 3) How would the process to migrate wiki users to osm.org based logins work? (Technically and practically) 4) Maintainability going forward, if custom code is used, it needs to be maintained going forward. I would absolutely appreciate any help getting this working. -- Firefishy (talk) 11:57, 5 August 2022 (UTC)

Resolved: seems solved Mateusz Konieczny (talk) 05:54, 28 August 2022 (UTC)

Data tables

The largest pages on this wiki weigh in at upwards of 1 megabyte. This is forcing Firefishy to dramatically increase the cache size in order to facilitate an offline dump of the wiki's contents. [4]

Many of these pages are giant tables containing spreadsheet-like data. Most of them represent imports of external datasets, database query results, or annotated OSM data. They don't seem to be benefiting at all from wiki formatting or collaborative editing. (By contrast, at least ‎Default speed limits has copious inline citations and ‎NAICS/2022 welcomes contributions, and both use {{Tag}} so they show up in Special:WhatLinksHere.)

Can we consider some alternatives?

• Special:Upload an OpenDocument spreadsheet (.ods) and link to it. Users would need to download LibreOffice to view these files.
• Upload an OpenDocument spreadsheet to OSMF's NextCloud instance for collaborative editing and online viewing.
• Post to Gist as CSV. It's version-controlled and allows rudimentary collaborative editing, and there's even a handy inline search feature.
• Install mw:Extension:JsonConfig and either
  • create a page with a JSON data model (e.g., ‎Ca:Catalunya/Revisió Poblacions Catalunya/taula.json. Not very pretty to look at but functional.
  • create a data table page in the Data: namespace. Pretty, with an interactive spreadsheet editing UI, and queryable in Lua modules.
• Eviscerate the page as the table is no longer relevant.

 – Minh Nguyễn ^💬 20:33, 8 August 2022 (UTC)

I opened https://wiki.openstreetmap.org/wiki/Talk:Romanian_Postal_Codes#Is_it_used_or_maintained%3F asking whether anyone is editing it. Judging by https://wiki.openstreetmap.org/w/index.php?title=Romanian_Postal_Codes&action=history it is clearly abandoned Mateusz Konieczny (talk) 20:41, 8 August 2022 (UTC)

Is only the current page size causing problems? Would it help to reduce page size or split it? Mateusz Konieczny (talk) 20:45, 8 August 2022 (UTC)

Yes, only current page size (latest revision) matter. -- Firefishy (talk) 22:46, 8 August 2022 (UTC)

@Firefishy: Is the current situation (with Leaderboard by some organised mapping taking 1.5M) still a problem? Do you know how large page is still going to cause problem? Mateusz Konieczny (talk) 08:48, 14 August 2022 (UTC)

I think for the moment that page is ok because it doesn't use many templates. Not seen any recent timeouts from that page. -- Firefishy (talk) 11:08, 14 August 2022 (UTC)

Resolved: seems solved for now 05:53, 28 August 2022 (UTC)

Tracking Commons file usage

I've just proposed over on Wikimedia Commons that Commons should start keeping track of which of its files are used by the OpenStreetMap Wiki. The proposal is at c:Commons talk:Tracking external file usage#Proposed target: OpenStreetMap Wiki. This would mean that uses of Commons' files on this wiki would be more visible to people dealing with them on Commons, similarly (though not identically) to the way uses on Wikimedia projects are visible. At a technical level, this would be implemented by a Commons bot that would use the public API on this wiki to occasionally fetch a list of all files used here and filter out the ones that come from Commons. I've run the fetching side by hand a few times to check it isn't outrageously slow. I'd be interested to know if people here think this would be useful, or problematic. --Ben Harris (talk) 14:58, 18 August 2022 (UTC)

That would be a great and welcome thing! Mateusz Konieczny (talk) 19:13, 18 August 2022 (UTC)

I think it's a wonderful and a useful idea ! — Koreller (talk) 09:59, 19 August 2022 (UTC)

Now on https://commons.wikimedia.org/wiki/Commons:Files_used_on_OpenStreetMap ! Via https://commons.wikimedia.org/w/index.php?title=Category:Commons_pages_with_broken_file_links&from=Files+used+on+OpenStreetMap it can be also used to detect broken data (see https://commons.wikimedia.org/wiki/User_talk:Bjh21#Detecting_nonexisting_files for some alternatives) Mateusz Konieczny (talk) 05:53, 28 August 2022 (UTC)

Resolved: Thanks for running this bot! Mateusz Konieczny (talk) 05:53, 28 August 2022 (UTC)

"is prohibited" (Q8001) is misleading

Resolved: I guess that anyone interested could become aware of this or will be by looking at history, discussion there also had some effect from what I see Mateusz Konieczny (talk) 11:34, 5 August 2022 (UTC)

See https://wiki.openstreetmap.org/wiki/Item_talk:Q8001

Data items use very string language to claim that it use of certain tags on nodes/ways/relations is "prohibited".

This is quite misleading, even in cases where it is quite bad idea it is not prohibited and in some rare cases may make sense.

Maybe "not recommended" would be better?

Strictly speaking it is not about OSM Wiki, but... Mateusz Konieczny (talk) 20:18, 29 July 2022 (UTC)

@Mateusz Konieczny:I think it's OK to use this page as a catch-all for discussions that don't have an obvious home elsewhere on the wiki. Item talk pages are quite obscure, so it's reasonable to surface those discussions in a more visible place like here, though Talk:Data items would've been another option. Now that you've flagged the discussion over here, let's continue it over there. :^)– Minh Nguyễn ^💬 20:34, 29 July 2022 (UTC)

deprecate status=import in favour of status=imported?

We have tag pages with both status=import and status=imported with the same meaning what is annoying and duplicative without good justification and some negative effects.

I propose to deprecate status=import and use just status=imported Mateusz Konieczny (talk) 17:54, 29 August 2022 (UTC)

+1 AngocA (talk) 20:17, 29 August 2022 (UTC)

+1 Chris2map (talk) 17:34, 30 August 2022 (UTC)

@AngocA: @Chris2map: Category:Feature descriptions with incorrect status value now complains also about status=import with status=imported expected to be used Mateusz Konieczny (talk) 07:21, 1 September 2022 (UTC)

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

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

Hi everyone,

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

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

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

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

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

Ok, so it's seems that we can simply remove the parameters "onNode, onWay, onArea and onRelation" to get the 'fallback' values defined here Item:Q5015 in "use on nodes", "use on ways", "use on areas" and "use on relations". (The job is done by the module Module:DescriptionFromDataItem.)

So I'm just gonna edit highway=footway and remove the 4 parameters "onNode, onWay, onArea and onRelation".

Anybody is against my solution? --Binnette (talk) 11:37, 9 October 2020 (UTC)

BTW, we may consider to remove those 4 parameters for all tags wiki articles. So we will may be need a bot... --Binnette (talk) 11:49, 9 October 2020 (UTC)

It’s also worth checking while you’re there whether anything is in the data item is language-specific (images are not so bad but check the rest). --Andrew (talk) 20:55, 9 October 2020 (UTC)

If you delete the VD parameters ("onNode, onWay, onArea and onRelation") you will loose the taginfo displaying compatibility :-( , see on this table: https://taginfo.openstreetmap.org/tags/highway=footway#wiki --MalgiK (talk) 21:56, 9 October 2020 (UTC)

Please don't delete the parameters from the actual wiki pages. I also think that a bot is the incorrect way to do this. The right way is to check how each tag is actually being used (by looking at taginfo and overpass-turbo) and make sure the description in the wiki matches how the tag is used by most mappers. --Jeisenbe (talk)

Please don't delete any parameters at all. It is fine to edit them, but I am not OK at all with deleting such content from OSM Wiki pages and relying on this data items (there was a big discussion about this already). Note that for translation in a given language it is possible that there is agreement to give up on maintaining this and use unreliable data items. Mateusz Konieczny (talk) 08:15, 10 October 2020 (UTC)

Discussion was on this very page, see Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information Mateusz Konieczny (talk) 08:26, 10 October 2020 (UTC)

"So I want my bot to check for those issues and 'print' a report. So a regular user can try to fix those issues. " - it exists already, see list of mismatches at https://wiki.openstreetmap.org/wiki/Category:Data_item_issues Mateusz Konieczny (talk) 08:18, 10 October 2020 (UTC)

For example https://wiki.openstreetmap.org/wiki/Category:Mismatched_onNode (I am not using this as in 99+% cases either translations or data item is wrong - and I do not care about data items and I edit only Polish translation, and even mismatches between PL and data items are generally data item mistakes) Mateusz Konieczny (talk) 08:20, 10 October 2020 (UTC)

@Binnette: I am not yet comparing between languages, but I nearly wrote such bot myself. See User:Mateusz Konieczny/TODO for typical output, code is at https://github.com/matkoniecz/osm_wiki_tag_api If you are interested specifically in log about conflicts between English and French Wiki entries (or maybe French OSM Wiki vs Data items conflicts) I can generate something in format that you want Mateusz Konieczny (talk) 14:43, 10 January 2021 (UTC)

Resolved: Mateusz Konieczny (talk) 05:56, 28 August 2022 (UTC)

Give auto-confirmed after 2 days, not 4?

Resolved: some parts are done --Tigerfell  (Let's talk) 13:35, 3 August 2022 (UTC)

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

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

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

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

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

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

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

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

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

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

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

The pull request was merged. There are still some unintended differences in permissions between autoconfirmed and manually confirmed users. However, CAPTCHAs are disabled and uploads are permitted for them, so I think the main issue is solved. If someone is in a similar situation, you can get in touch with any wiki administrator or bureaucrat who can manually confirm the account i. e. add the user to the "confirmed" user group. --Tigerfell  (Let's talk) 13:35, 3 August 2022 (UTC)

Category Tree extension missing

Resolved: extension added --Tigerfell  (Let's talk) 13:10, 3 August 2022 (UTC)

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

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

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

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

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

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

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

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

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

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

CAPTCHA

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

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

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

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

See https://github.com/openstreetmap/operations/issues/19 for some context. "I switched to FancyCaptcha for awhile and got shouted at because blind users were unable to complete the captcha.". I am unfamiliar with Wikipedia's captcha (is it usable by us?), but you may try opening a new issue there proposing such change Mateusz Konieczny (talk) 10:12, 18 January 2020 (UTC)

Yeah it seems Wikipedia's captcha has the same problem. I wonder if it could be possible to create some sort of fallback where people can choose to solve Google's captcha if they can't solve the one that doesn't have audio fallback. Rostaman (talk) 02:45, 22 January 2020 (UTC)

It is probably one of cases that are in category of "will be not fixed without someone willing to write necessary code/configuration updates, current contributors are unlikely to have time for that" Mateusz Konieczny (talk) 10:04, 22 January 2020 (UTC)

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

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

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

As a follow-up, I suggested to disable CAPTCHA and check if spam increases significantly. openstreetmap/operations/issues/383 --Tigerfell  (Let's talk) 10:57, 26 March 2020 (UTC)

{{Stale|No progress on the technical side. --Tigerfell  (Let's talk) 12:03, 3 April 2022 (UTC) }}

There is now "We have switched to hCaptcha. I have kept the instances the captcha is used to a minimum." at https://github.com/openstreetmap/operations/issues/383 so seems to be done now? Is the new captcha also problematic? Mateusz Konieczny (talk) 10:35, 2 September 2022 (UTC)

I think this is somehow resolved now. --Tigerfell  (Let's talk) 22:15, 2 September 2022 (UTC)

Resolved: Mateusz Konieczny (talk) 13:04, 13 September 2022 (UTC)

Bug displaying images on Discussion pages in Mobile View ?

When you switch to Mobile view, images are converted to

<img>

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

<span ...> </span>

. This makes them appear as whitespace.

This does not happen in "Desktop" view.

Example: Insert the following template

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

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

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

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

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

.

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

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

Resolved: Given no reply, I assume that it works now Mateusz Konieczny (talk) 11:35, 6 September 2022 (UTC)

Mobile frontend UI - appearance of mobile view

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

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

Resolved: I think that this welcome request can be archived now Mateusz Konieczny (talk) 11:37, 6 September 2022 (UTC)

Template documentation structure

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

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

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

=== Usage ===

=== See also ===

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

</includeonly>

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

So I propose the following structure :

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

=== Notes ===

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

== Parameters ==

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

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

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

</includeonly>

See for exemple this template : Template:Bing image

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

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

OK to me. One question:

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

@Chris2map Yes of course !

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

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

So I do the change today in this diff — Koreller (talk) 13:38, 18 August 2022 (UTC)

Resolved: Mateusz Konieczny (talk) 19:55, 13 September 2022 (UTC)

Template:KeyPrefixDescription

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

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

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

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

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

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

What do you think about this new template?

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

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

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

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

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

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

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

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

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

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

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

I like "qualifier prefixes" name. "meta keys" is more fitting for source=* and check_date=* or note=* Mateusz Konieczny (talk) 11:36, 5 August 2022 (UTC)

Resolved: that went through a proposal and got implemented Mateusz Konieczny (talk) 19:55, 13 September 2022 (UTC)

Rewriting Map Features

I am proposing to change Map Features to avoid hitting resource limits and support documentation pages that use the Translate extension. --Andrew (talk) 06:14, 28 July 2022 (UTC)

Resolved: seems applied, anyway people here were notifiedMateusz Konieczny (talk) 19:53, 13 September 2022 (UTC)

Redundant pages for "building block" tags

Resolved: It seems that pressure was reduced by generating compound listings, but there is no clear consensus to ban creation of such pages or data items. There is also no clear support for deleting such data items or wiki pages. But creation of such pages is at least discouraged. Mateusz Konieczny (talk) 12:55, 13 September 2022 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Enhanced not-found messages

Resolved: this helpful functionality was added, extra request/proposals for improvement are likely better to be discussed separately Mateusz Konieczny (talk) 11:38, 6 September 2022 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Enhanced not-found messages for logged out users

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

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

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

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

Enhanced not-found messages for non-English users

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

Resolved: solved here, as I extracted it to a new section to allow parent section to be archived Mateusz Konieczny (talk) 11:40, 6 September 2022 (UTC)

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

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

Marking incomplete compound pages

Resolved: I still think that it is a good idea, but I guess that I should implement this if I really want it. Marking as solved here to allow parent sections (there are two levels!) to be archived Mateusz Konieczny (talk) 11:43, 6 September 2022 (UTC)

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

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

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

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

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

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

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

data items about compound keys

Resolved: It seems that there is no consensus for deleting either such data items or such wiki pages, but one should not create either blindly if standard display of compound key structure is good enough Mateusz Konieczny (talk) 11:44, 6 September 2022 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

Hey @Mateusz Konieczny:. Minh seems to have preempted my thoughts on data items pretty well. I'm not hugely concerned about maintainability as a lot of that can be mitigated with tools, templates, etc. I'm more concerned about usability and navigability for newer editors. It can be very confusing to understand the "correct way" to tag a bus lane, for example, and I'd generally prefer to have fewer pages which cover a concept or thing than spreading compound tags over many pages (Bus lanes vs lanes:psv:forward). Diacritic (talk) 04:38, 25 July 2022 (UTC)

@Diacritic: - "I'm more concerned about usability and navigability for newer editors." I actually run into it again. I needed to check meaning of name:sq key, went to Key:name:sq that at this time redirected to Names#Localization which has not mentioned it. I edited this page so that user using it will actually have that info available. I am planning to do this with other language pages which are now redirect, I am also considering to do it with other name:XYZ pages which are about used tags and have no compound page such as https://wiki.openstreetmap.org/wiki/Key:name:ab Maybe allso for all name tags which have a matching data item (as all arguments that were raised to not creating wiki page apply also to not creating data items) Mateusz Konieczny (talk) 15:13, 24 August 2022 (UTC)

Lets say that someone encountered lanes:psv:forward=* and is a newbie and never heard about "PSV" terms. Why short page on Key:lanes:psv would make situation worse? In many cases such dedicated page would not be useful for people learning more about bus lanes but would be still useful for someone wishing to learn what is the meaning of a given tag @Diacritic: (Though Key:lanes:psv:forward is likely not needed except as a redirect which exists now. Neither data item nor osm wiki page is really useful there - though https://wiki.openstreetmap.org/wiki/Item:Q3548 should be likely deleted or marked as redirect Mateusz Konieczny (talk) 07:04, 25 July 2022 (UTC)

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

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

@Mateusz Konieczny: What I meant is that a redirect page isn't as helpful to software that just needs a concise description or representative image for the key, as opposed to the broader context. The relevant information is buried somewhere on the target page in an unstandardized format, maybe in a table, a list, a poorly written paragraph, or nowhere at all, but it wouldn't be in an infobox. Recently someone was even promoting the idea of redirecting from keys like noexit=* to noexit=yes. To the extent that we continue to encourage redirects, data items are essential for transparency to data consumers. – Minh Nguyễn ^💬 06:55, 25 July 2022 (UTC)

@Minh Nguyen: Ah, now I understand. Yes, if we would make such redirects mandatory and creating of description pages forbidden then content of such forbidden pages would need to be put somewhere (though I prefer creating such pages instead) Mateusz Konieczny (talk) 07:01, 25 July 2022 (UTC)

"name:th (Q1577) is an example of a data item that exists even though name:th=* is a redirect" - actually, I am considering creation of name:$lang pages on OSM Wiki for all valid codes which are in use. Though if display of compound pages can become reliable then it is likely good enough. I think that what is missing for now is always displaying compound list, no matter whether dedicated data item exists or not and to ensure that it is shown to all people no matter browser language. BTW, thanks for inventing, creating and keeping to improve that! It actually convinced me that there is some benefit from data items (still not convinced that net effect of that experiment is positive or worth the effort, but maybe I am wrong here). Hopefully my endless comments here are not too annoying. @Minh Nguyen: Mateusz Konieczny (talk) 08:46, 24 July 2022 (UTC)

@Mateusz Konieczny: I agree, users do need consistency, or else they won't have enough trust in these features. I think what I'm struggling with is how best to surface parts "foo" and "bar" when "foo:bar" is documented. We could list their descriptions in a nested list, but that could get repetitive, and in some cases "foo:bar" is documented precisely because the "foo" and "bar" descriptions don't make much sense in combination. (Separate pages about prefixes might help with this.) I'm glad you're finding these explorations to be fruitful. Hopefully we can arrive at something that works for everyone long-term. – Minh Nguyễn ^💬 06:55, 25 July 2022 (UTC)

name:mos

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

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

Is it fixable? Or maybe this tag is invalid?

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

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

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

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

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

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

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

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

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

Migrate taginfo to AJAX-based rewrite

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

Resolved: I think that this notification can be now hidden Mateusz Konieczny (talk) 13:43, 17 September 2022 (UTC)

EWG projects to improve wiki software

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

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

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

That sounds great!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I attended the meeting on 6th June. The outcome can be found in the minutes.

MultiMaps: I do not see a future in maintaining this extension personally. About the same time it became clear that MultiMaps does not work with MediaWiki starting in version 1.38 to which OWG has to update by November for security reasons. That is why we focused on adapting Kartographer extension to this wikis needs. I wrote a list of requests that should be implemented to make Kartographer a suitable replacement for MultiMaps i. e. without loosing any features. The requests were forwarded to FOSSGIS because they are in touch with the technical team of Wikimedia Deutschland. They in turn said that they will focus on WMF's needs for this year. I made aware OWG by opening issue openstreetmap/operations/issues/749 (you will find further information there).

Single Sign On: EWG is essentially willing to invest time and efforts into this project. However, they want to clarify the scope and goal of the suggestion before turning it into a project. Some of the points in need for clarification are stated in the minutes. Ideally, they want to have a discussion and a conclusion by the wiki community. The subject itself has been discussed plenty of times but the bullet points where not clarified. I currently do not have the time to guide and focus a discussion like this (you might have noticed that I am less frequently writing in the wiki for the last months, too). EWG was essentially looking for somebody who wants to do that. So this is the chance for somebody to raise their hand and bring this to a positive end ... :-).

Cheers --Tigerfell  (Let's talk) 20:41, 29 September 2022 (UTC)

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

- the lack of people to translate

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

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

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

@Tordanik: - maybe How one may create account while hit by "listed as an open proxy in the DNSBL" is relevant? At least documenting what is going on here. Mateusz Konieczny (talk) 19:19, 24 September 2022 (UTC)

I think this is pretty irrelevant to EWG. OWG want to limit the wiki spam from their side so they decided to use the DNS blacklist in this wiki. If they want they can simply switch off this feature. --Tigerfell  (Let's talk) 20:41, 29 September 2022 (UTC)

Resolved: it appears that this discussion can be now archived Mateusz Konieczny (talk) 06:35, 29 September 2022 (UTC)

Proposed bot to make files used in data items appear to be used

I'd like to propose running a bot to maintain a gallery of files used by data items on the OpenStreetMap Wiki.

As mentioned above, files referenced by image (P28) and OSM Carto image (P39) don't get tagged as being used on their file pages. This in turn means that where those files come from Wikimedia Commons they don't appear in c:Commons:Files used on the OpenStreetMap Wiki. Minh Nguyen indicated that this is a feature of how images in Wikibase are handled on this wiki. On Commons, I run a bot that maintains galleries of files used on other projects so that they are marked as being in use on Commons, and I've extended that bot so that it could maintain such galleries for files used by data items on the OpenStreetMap Wiki. I've made a gallery containing a sample 1,000 of the files at User:Ben Harris/Usage sample. The full set of used files would take five galleries. Would such a bot be welcome here? It would initially maintain five galleries like that, which could be placed under Wiki:Files used in data items. --Ben Harris (talk) 22:01, 7 September 2022 (UTC)

@Ben Harris: (1) it seems to be on User:Ben Harris/Usage demo (2) I support such workaround for this specific deficiency of data items, unless there is a better way to do this (3) bot edits will be marked as bot edits, right? (4) how often this edits would be run (5) where source code is published? Mateusz Konieczny (talk) 22:41, 7 September 2022 (UTC)

@Mateusz Konieczny: (1) Correct. Sorry! (3) If the bot's account gets the bot flag then it'll mark its edits as bot edits. (4) Currently I expect to do a weekly batch of edits just before the run that updates c:Commons:Files used on the OpenStreetMap Wiki. Within the batch, edits would be every five seconds. Either of these could be changed if required. (5) The source code is at https://github.com/bjh21/usage-bot/tree/osm-wikibase. I'll merge it into the main branch if I start running the bot here. --Ben Harris (talk) 09:51, 8 September 2022 (UTC)

For context, this is a continuation of the discussion at Commons. I'm not certain why OSM Wikibase is storing the file names as strings instead of file references. Wikibase's built-in Commons media file type apparently does support local files, although it falls back in the wrong direction. Storing the file names as file references would make Special:WhatLinksHere work automatically and obviate the need for JavaScript-based workarounds.

I wouldn't be opposed to your bot maintaining a gallery like this, but in the long term, I think it would be better if your Commons bot could query Sophox for these images (which has an API endpoint in XML or JSON). That way there isn't anything extra to maintain. I don't think the code to parse Sophox results would be more complex than what you're currently using to discover images via the Wikibase API. You could use SPARQLWrapper to avoid writing manual networking code.

In the meantime, if there are no concerns about the stopgap approach, an administrator can grant your account a bot flag to hide it from Special:RecentChanges by default, but it needs to be a separate account, perhaps by the same name as c:User:Usage Bot.

 – Minh Nguyễn ^💬 01:00, 8 September 2022 (UTC)

@Minh Nguyen: I admit I've avoided Sophox because it would require learning SPARQL. Maybe I have to accept that I can't avoid SPARQL any longer. I would of course run the bot under its own account. Should I create that account now? I know on Commons bot accounts are meant to be created before asking permission to run them, but I don't know what the usual procedure is here. --Ben Harris (talk) 09:51, 8 September 2022 (UTC)

@Ben Harris: there are no really strict decided procedures here, especially about bots. We do not have even decided procedure how to deal with files on unclear licensing status. Feel free to create an account and just ask for a bot flag based on the discussion here (maybe give few more days for more comments) Mateusz Konieczny (talk) 10:56, 8 September 2022 (UTC)

Thanks, Mateusz Konieczny! I've created the bot account (User:Usage Bot) and made a test run that's populated the first four pages of Wiki:Files used by data items (I changed "in" to "by" based on the phrasing of file pages). The bot ran into a CAPTCHA trying to create the fifth gallery, so please could a bureaucrat grant it the bot flag? @Harry Wood: You seem to have flagged most recent bots, could you please flag Usage Bot? The first scheduled run of the bot will be on Monday morning. --Ben Harris (talk) 14:44, 10 September 2022 (UTC)

OK. I've put Usage Bot in the 'bot' group. Sounds like a harmless bot use as long as you don't hammer our wiki server too heavily! -- Harry Wood (talk) 16:35, 11 September 2022 (UTC)

Thanks, Harry Wood! The bot's edits overnight didn't run into any problems and got properly marked as bot edits. The thing that seems to cause the most load on the wiki server is actually when the bot queries the list of files in use to update c:Commons:Files used on the OpenStreetMap Wiki. The allfileusages API is quite slow: it took the bot 48 minutes to get the whole list today. --Ben Harris (talk) 13:21, 12 September 2022 (UTC)

@Ben Harris: Welp, seems like Sophox might not be a great way to do this at the moment anyways. It seems to be dropping data items for some reason. [8] – Minh Nguyễn ^💬 19:31, 9 September 2022 (UTC)

Resolved: Thanks for this listings! Mateusz Konieczny (talk) 12:39, 13 September 2022 (UTC)

Is it OK to assume Wiki license for files uploaded without explicit licenses and are marked as own work?

See https://wiki.openstreetmap.org/wiki/Talk:Wiki#Designing_policy_for_handling_files_without_clear_license and https://wiki.openstreetmap.org/wiki/File:Brake-Bahnhofstrasse.jpg Or File:Challenges.png

How https://wiki.openstreetmap.org/wiki/File:Brake-Bahnhofstrasse.jpg should be marked?

It was uploaded without license and marked as own work. Should we apply "Content is available under Creative Commons Attribution-ShareAlike 2.0 license unless otherwise noted." and assume that author could license it this way?

With {{CC-BY-SA-2.0-self}}? Create new {{Assumed-CC-BY-SA-2.0-self}} for such cases to give warning to potential reusers? Delete as missing a clear license?

Mateusz Konieczny (talk) 21:23, 14 September 2022 (UTC)

We don't need to delete an image if we believe that it has been uploaded to the OSM wiki by its creator. So depending on whether we conclude that the upload dialog makes/made it clear that the wiki's content license will also apply to images by default, I see the options of either marking it as CC BY-SA 2.0 (possibly with a different template for this particular case) or marking it as an image that is not available under an open license, but which we are permitted to use on the OSM wiki. (Is there something like {{Nonfree-self}}?) The latter option would be the safer choice because it does not risk any questionable legal assertions, but of course we'd like as many images on the OSM wiki as possible to be available under an open license. --Tordanik 20:12, 18 September 2022 (UTC)

{{Assumed-CC-BY-SA-2.0-self}} now exists and I applied it to File:Brake-Bahnhofstrasse.jpg Mateusz Konieczny (talk) 21:26, 22 September 2022 (UTC)

Resolved: Mateusz Konieczny (talk) 03:21, 30 September 2022 (UTC)

Consider changing wiki license to CC BY-SA 4.0 to avoid copyleft trolls

see https://creativecommons.org/2022/02/08/copyleft-trolls/

--Stephankn (talk) 18:25, 24 September 2022 (UTC)

See https://wiki.openstreetmap.org/wiki/Talk:Wiki#Updating_the_wiki's_license Mateusz Konieczny (talk) 19:20, 24 September 2022 (UTC)

Resolved: @Stephankn: - can you continue in the existing thread? Mateusz Konieczny (talk) 19:20, 24 September 2022 (UTC)

Introducing a more user-friendly UI for proposal voting via an extension

Resolved: Superseded by Talk:Wiki#RFC: Two new extensions for the wiki: Log in via openstreetmap.org and vote via a GUI.

Inspired by @Martianfreeloader:'s suggestion to implement an easier in-wiki voting system I overcame my aversion for PHP and developed a small MediaWiki extension.

I also recorded a small demonstration video. (Note that when the form couldn't be submitted because no comment was entered, the browser actually shows a Please fill out this field. message ... OBS just failed to record that.)

The cool thing about my extension is that the votes are still stored in the wikitext, which means that the changes can still be tracked in the page history. And proposal authors can also respond to votes by just editing the wikitext and adding a line like they're used to. But at the same time people who have never edited a wiki page can just add (or even change) their vote without needing to read instructions or wrap their head around snakes like --~~~~ ;)

--Push-f (talk) 19:12, 4 October 2022 (UTC)

That's brilliant and very well done! I'm quite surprised that after all these since MediaWiki was created, and given the importance of community polls for decision-making, that no such extension had been developed until now. This one would definitely warrant a prominent place at mw:Category:Poll extensions :)

Two small suggestions:

• When the end date of the vote is set in the past, only the votes cast before that date should be counted for the totals
• When a user changes their previous vote(s), the old ones should be rendered with strike-through or greyed-out (or both)

And just to be sure, the "Please fill out this field" message you mention above is due to a required attribute, like this? I tried reading the code but couldn't figure that out. —Preceding unsigned comment added by Waldyrious (talk • contribs)

Thank you, very good suggestions! I just implemented both. Yeah I'll document the extension on mediawiki.org once it is used on this wiki. And yes the required attribute is dynamically added/removed by this JavaScript code depending on the selected radio button (since approval votes do not require a comment). --Push-f (talk) 07:33, 8 October 2022 (UTC)

Ha, that was quick! I'm glad you found my suggestions useful.

I do have an additional question, which may pose more of a design challenge: would it be possible to have a discussion under the votes? Would it be a matter of nesting content under the bullet entries with ** or *:, etc.? Or would the extension be unable to parse votes if such extra content is added? In particular, would one still be able to change a vote that has had discussion underneath?

A second question, that just occurred to me: if someone manually adds a duplicate entry to the wikitext, would the extension be able to not count it for the totals? Or is that deliberately ignored as part of the vote manipulation issues that should be handled by humans (such as simulating votes by other people, adding back-dated votes after a proposal is closed, unilaterally altering the deadline of a vote, etc.)? --Waldyrious (talk) 12:00, 8 October 2022 (UTC)

Within the <vote> tag any line that starts with *␣ is attempted to be parsed as a vote. All other lines are simply passed through and ignored in regards to the vote tallying. So it is perfectly possible to reply to votes with ** or *: ... with one caveat: ~~~~ is unfortunately not expanded because the MediaWiki parser does not expand signatures within tags. I think that this has to be addressed on MediaWiki's side and I filed phabricator:T319221 for that.

The extension only counts the last vote of a given user (before the end date if there is any). So duplicating lines does not duplicate votes, only the last vote is counted. --Push-f (talk) 14:11, 8 October 2022 (UTC)

I see, thanks for clarifying. The signature limitation is quite relevant for a voting extension. Considering that it can take quite a while for a MediaWiki issue to be addressed, it may be better to introduce a workaround for the time being, in the form of a new feature in the extension allowing the addition of comments to existing votes, possibly with a UI/UX similar to the new Reply tool being deployed in Wikimedia wikis (additional screenshots can be found here, if helpful). WDYT? --Waldyrious (talk) 15:12, 8 October 2022 (UTC)

I managed to come up with a workaround, so using ~~~~ within the <vote> tag now just works as expected. A dedicated UI for replying to votes would definitely go beyond the scope of my little extension. --push-f (talk) 18:23, 8 October 2022 (UTC)

That's pretty clever! I can't think of anything else that may be needed for this to be adopted here (and I'd argue also in other wikis in the Wikimedia universe, which also makes frequent use of such votes). Again, nice work! --Waldyrious (talk) 20:27, 8 October 2022 (UTC)

@Push-f: Neat, thanks for exploring a fresh approach to voting here. Do you know if the extension is compatible with Visual Editor? For example, if I subsequently use Visual Editor to modify the page's other contents, will it disturb the <vote> tag? Administrators here can't install extensions, so once you feel good about the extension, the next step would be to ask the sysadmins to review it.

By the way, I think the reason voting extensions aren't more common on Wikimedia wikis is that more people are comfortable with JavaScript than PHP, so they write user scripts like w:User:Awesome Aasim/xfdvote. (Twinkle also has voting buttons, but it's overkill for this purpose.) Administrators can install these user scripts as gadgets and enable them by default for all users, as we've done to support the new {{Taginfo2}} boxes. In general, user scripts are less risky from a security standpoint, but an extension would be able to support users who have JavaScript disabled and potentially integrate with MediaWiki functionality that isn't exposed through the UI.

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

Thanks! I haven't tried it with VisualEditor since that extension is cumbersome to install but I think it should work fine.

I also just set up a demo wiki where you can try out the extension, see #RFC: Two new extensions for the wiki: Log in via openstreetmap.org and vote via a GUI.

I'll open the respective GitHub issues/pull requests once I have gotten more community feedback. --push-f (talk) 10:00, 13 October 2022 (UTC)

As it turns out VisualEditor no longer requires Node.js, so I just tried it and it works perfectly :) --push-f (talk) 07:56, 14 October 2022 (UTC)

Remove wikidata parameters from infoboxes

I want to propose bot edit removing wikidata parameter from infoboxes (see Proposed features/remove link to Wikidata from infoboxes for why this nonfunctional parameter is on many pages - in the past it was shown)

Edits would look like this: https://wiki.openstreetmap.org/w/index.php?title=Cs:Tag:amenity%3Dbicycle_parking&diff=prev&oldid=2389902

Would be done from bot account, I would either create new one or use User:MissingImageInfoBot Mateusz Konieczny (talk) 19:50, 13 September 2022 (UTC)

As long as the values are already in the corresponding data items, I don't see why it would matter one way or another, since the parameter has no effect. But if seeing fewer QIDs in source editing mode makes you happier, sure, I guess? – Minh Nguyễn ^💬 04:12, 14 September 2022 (UTC)

They were migrated before Proposed features/remove link to Wikidata from infoboxes vote started Mateusz Konieczny (talk) 06:03, 14 September 2022 (UTC)

"I don't see why it would matter one way or another" - removes one more potential source of confusion for new users and reduces risk that someone can start improving/adding parameter which is deprecated - n such case they should do it in data items Mateusz Konieczny (talk) 13:33, 17 September 2022 (UTC)

@Harry Wood: - can I get bot flag for User:Mateusz Konieczny - bot account? Mateusz Konieczny (talk) 13:29, 17 September 2022 (UTC)

https://wiki.openstreetmap.org/wiki/Special:Contributions/Mateusz_Konieczny_-_bot_account made some demonstration edits Mateusz Konieczny (talk) 13:03, 18 September 2022 (UTC)

Resolved: Mateusz Konieczny (talk) 09:46, 7 October 2022 (UTC)

Graphical improvements to the Wiki

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Koreller: Is nay further feedback needed here? Mateusz Konieczny (talk) 19:08, 24 September 2022 (UTC)

@Mateusz Konieczny: OSM has no coherent graphic charter (where is no "OSM-like look" guideline), its website as well as the tools do not use a coherent style. I do not have the competence, the time, the desire to create a graphic charter. What I understood is that part of the community does not want any graphic improvement so I gave up the idea. Or maybe I misunderstood? — Koreller (talk) 13:06, 25 September 2022 (UTC)

@Koreller: "part of the community does not want any graphic improvement" that mist be really tiny part. In general all kinds of improvements are welcome! Sadly, with graphic design specifically I am not really going to be helpful. But also small improvements are welcome, and most of projects in OSM are done because someone really wanted something to be done Mateusz Konieczny (talk) 18:20, 11 October 2022 (UTC)

@Mateusz Konieczny: I guess I don't wish it enough unfortunately. I really wanted to make a contribution guide on a country and that went really well — Koreller (talk) 20:21, 11 October 2022 (UTC)

Resolved: resolved not in some uplifting way, still it is resolved Mateusz Konieczny (talk) 21:00, 11 October 2022 (UTC)

Container categories category

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

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

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

Resolved: Mateusz Konieczny (talk) 09:45, 7 October 2022 (UTC)

Taglists currently don't seem to be working as expected

They have empty columns for Element, Description, Map rendering & Image.

Example:

◆ Taglist ... 

LOADING TAG LIST...

Is this a wiki issue, or do we need a ticket for taginfo on GitHub? taginfo/taginfo --MalgiK (talk) 00:32, 26 October 2022 (UTC)

Can anybody confirm the empty table cells for columns Element, Description, Map rendering, Image, or does this happened only on my machine?--MalgiK (talk) 03:14, 28 October 2022 (UTC)

Seems fixed, see https://github.com/taginfo/taginfo/issues/380 --MalgiK (talk) 08:10, 28 October 2022 (UTC)

Quality section

I wrote it in response to "I thought we could treat the wiki as authoritative?and everything else not in the wiki as a wrong or mistaken, or unsupported?" posting on talk mailing list.

See https://wiki.openstreetmap.org/wiki/Wiki#Quality

Review/improvements are welcome! Mateusz Konieczny (talk) 10:25, 18 October 2022 (UTC)

That's a great initiative, indeed this information was missing! I took the liberty to rename the section and do some copyediting. Please check it out and let me know what you think! --Waldyrious (talk) 16:28, 19 October 2022 (UTC)

I think that critical question and difference between our versions is about status of proposal process: is it mandatory to follow approved tagging? Is ATYL applying also to "you can ignore what proposal process decided"? As far as I see: yes, you can ignore proposal process and its decision, but it is quite rarely a good idea. @Waldyrious: Mateusz Konieczny (talk) 07:22, 20 October 2022 (UTC)

Hmmm. None of the wording used in ATYL seems to suggest that it's OK to ignore a proposal decision. I agree that it allows for initiating a tagging practice without going through the proposal process first, but once a proposal is approved, I would say that it is indeed "mandatory" (in the sense of a social convention, since technically you can always disregard it, of course) to follow its recommendations.

Reading your edits, I would therefore object to the statement "even in this cases it is not mandatory". That is IMO encouraging disregarding a process that multiple people went through the effort to coordinate, and it's not healthy for a functioning community.

I am also confused by this edit. What exactly do you mean by that? It seems a bit out of place. Maybe you meant it for the following paragraph? --Waldyrious (talk) 08:00, 20 October 2022 (UTC)

No, you are entirely free to ignore tagging recommended by approved proposal. You can also use tagging deprecated by proposal. I may need to dig a bit to find a good example, as nearly all approved proposals make sense Mateusz Konieczny (talk) 08:46, 20 October 2022 (UTC)

See say approved https://wiki.openstreetmap.org/w/index.php?oldid=589962 with "healthcare=hospital Replaces amenity=hospital.". Nevertheless using amenity=hospital without healthcare=hospital is 100% fine. (yes, this one may change at some point) Mateusz Konieczny (talk) 08:49, 20 October 2022 (UTC)

https://wiki.openstreetmap.org/wiki/Proposed_features/Ice_cream - but using shop=ice_cream is fine. Mateusz Konieczny (talk) 08:50, 20 October 2022 (UTC)

https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dport - using landuse=industrial industrial=port/industrial=harbour or landuse=commercial for light ports is both more common and makes more sense. Mateusz Konieczny (talk) 08:52, 20 October 2022 (UTC)

Just to be clear, I'm not arguing that going against the approved proposals in the wiki should be forbidden; I just don't think it should be encouraged. After all, this would only be justified in exceptional circumstances, since as you say yourself, "nearly all approved proposals make sense".

IMO if we just change the sentence like this:

Tagging that went through proposal process were discussed, reviewed and approved and is highly encouraged to be followed, but even in this cases it is not mandatory.

...would be sufficient to hint at that possibility (by saying "encouraged to be followed" rather than something like "must be followed"), without explicitly encouraging going against the community decisions. WDYT? --Waldyrious (talk) 12:00, 20 October 2022 (UTC)

That seems also fine, just do not declare it as authoritative/binding/banning alternatives. It can be described in greater detail elsewhere Mateusz Konieczny (talk) 12:04, 20 October 2022 (UTC)

Cool, will do. And what about this edit? It seems a bit redundant and I'd honestly be tempted to remove that sentence, unless I'm missing some important point. --Waldyrious (talk) 12:54, 20 October 2022 (UTC)

The intention was to distinguish pages which are 100% verified certified and correct (OEG), from ones where main point is definitely true from other pages which are more in flux. Feel free to improve or remove if unclear. Main point is anyway "wiki is useful and ignoring it is not going to be a good idea, but it is not some 100% certified word of God" Mateusz Konieczny (talk) 14:25, 20 October 2022 (UTC)

OK, got it. I think that point is already made clear with the existing content of the section (e.g. "Note that the Wiki can have mistakes..." and "The Wiki should not be treated as a final, fixed source of information", etc.), so I'll go ahead and remove that bit to avoid confusion and redundancy. --Waldyrious (talk) 15:37, 20 October 2022 (UTC)

Resolved: Feel free to improve it further! But I think this request can be archived Mateusz Konieczny (talk) 12:47, 28 October 2022 (UTC)

Page access MediaWiki:Gadget-taginfo.css

I wonder how the access of page MediaWiki:Gadget-taginfo.css is managed. I can't found it listed on the table of Special:ProtectedPages. Anybody has knowledge or can even do the proposed changes on the talk page MediaWiki_talk:Gadget-taginfo.css under Tweaking the tagbox? --MalgiK (talk) 14:24, 13 October 2022 (UTC)

The MediaWiki namespace is by default only editable by users with the editinterface right (which is included in the sysop user group), because it hosts content that controls the wiki's interface. The wiki's administrators should be able to make that change. --Waldyrious (talk) 15:35, 13 October 2022 (UTC)

@Waldyrious: Thanks a lot for detailed clarification! @Minh Nguyen: Since you moved the page User:ZeLonewolf/taginfo.css to the MediaWiki namespace and you are also an Admin, could you please make the changes? --MalgiK (talk) 16:59, 13 October 2022 (UTC)

@MalgiK: Fixed. – Minh Nguyễn ^💬 19:09, 13 October 2022 (UTC)

@MalgiK: Do we need to do anything else? Mateusz Konieczny (talk) 14:58, 19 October 2022 (UTC)

@Mateusz Konieczny: What do you mean in detail? (The access is restricted, some modifications are done)--MalgiK (talk) 15:08, 19 October 2022 (UTC)

@MalgiK: Is it now OK to archive this section - or are you proposing to do something additional Mateusz Konieczny (talk) 15:14, 19 October 2022 (UTC)

@Mateusz Konieczny: I see. Modifications are okay. I still wonder why this data needs to be saved/placed in the special admin restricted area. --MalgiK (talk) 15:33, 19 October 2022 (UTC)

"I still wonder why this data needs to be saved/placed in the special admin restricted area" - editing site .css allows performing large scale attacks. It is not as bad as allowing to edit .js of site, but still would allow at least to paralyse wiki. Mateusz Konieczny (talk) 07:35, 20 October 2022 (UTC)

@import could be abused for tracking too. --Nw520 (talk) 18:51, 20 October 2022 (UTC)

Resolved: seems resolved, right? Mateusz Konieczny (talk) 07:23, 29 October 2022 (UTC)

What is Wikiteam?

https://wiki.openstreetmap.org/wiki/Wiki#Wikiteam has very prominent description of "Wikiteam". I thought that it is some weird/cutesy way of referring to OSM Wiki editors but I also see https://wiki.openstreetmap.org/wiki/Category:Wiki_Team mentioned on Wiki as "all team members".

What is the point of that? Would it be OK to remove that mention of this "Wikiteam" and rephrase it as it describes OSM Wiki editors in general?

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

I assumed that "Wikiteam" meant volunteers (with special permissions or otherwise) willing to help with management of the wiki itself, including assistance with MediaWiki features, formatting, templates, categories, etc.. That's different from the entire contingent of wiki editors, many of whom may be here just to make content additions/improvements, i.e. not focused in the maintenance of the wiki at a meta level.

So I wouldn't favor removing that section, but perhaps it could be rephrased to be clearer. --Waldyrious (talk) 16:31, 19 October 2022 (UTC)

It's a very old idea by User:!i! and a few others a decade ago. IIRC the goal was for more experienced wiki contributors to (voluntarily) identify as part of the "wikiteam" with user page templates and sometimes special signatures. Besides participating in cleanup activities and such, these users would offer help to people who are only just learning how to work with MediaWiki. I don't think it's really a thing anymore. --Tordanik 19:43, 20 October 2022 (UTC)

I removed mentions of Wikiteam from Wiki as outdated Mateusz Konieczny (talk) 12:51, 28 October 2022 (UTC)

Resolved: marking as resolved - please mention if anyone disagrees with this edit Mateusz Konieczny (talk) 07:24, 29 October 2022 (UTC)

Empty search results for proposals that are in the voting phase

It seems the proposals which are having the status "voting", (therefore listed at corresponding category: Proposals_with_"Voting"_status) are not processed by the search function, examples e.g.:

• search query for amenity=mailroom
• search query for Key:pedagogy

Any idea why that happened? --MalgiK (talk) 07:08, 29 October 2022 (UTC)

Probably some internal wiki process again stopped. Are category listing and search results being updated in general? @MalgiK: Mateusz Konieczny (talk) 07:21, 29 October 2022 (UTC)

See https://community.openstreetmap.org/t/osm-wiki-no-updates-found-in-search-since-august/4738 - it may be worth reporting https://github.com/openstreetmap/operations/issues but due to lack of Mediawiki experts I would not expect a resolution happening soon. https://wiki.openstreetmap.org/w/api.php?action=query&meta=siteinfo&siprop=statistics seems to indicate that job queue is again full, for whatever reason. Maybe someone can pinpoint when problems started? (I hope it was not triggered by that large scale bot edit that I did) Mateusz Konieczny (talk) 07:42, 29 October 2022 (UTC)

Thanks a lot for response, how do you recongnize in detail at statistics: current "jobs": 23152289, that the job queue is full? --MalgiK (talk) 08:12, 29 October 2022 (UTC)

I admit that I am unsure how to interpret this info Mateusz Konieczny (talk) 08:33, 29 October 2022 (UTC)

Don't know how to check if category listing and search results are updated in general.--MalgiK (talk) 08:15, 29 October 2022 (UTC)

Look at some recent edits that should result in this changes and check whether changes happened @MalgiK: Mateusz Konieczny (talk) 08:33, 29 October 2022 (UTC)

I confirm, the search index seems not updated in general, because i did a check by searches for titles on this talk page (result okay for a title on 2nd June 2022 and no results for a title on 19th August 2022) --MalgiK (talk) 08:57, 29 October 2022 (UTC)

Resolved: should be fixed now Mateusz Konieczny (talk) 07:05, 3 November 2022 (UTC)

Template:WikidataSPARQL

Would it be desirable to have the Template equivalent to https://www.wikidata.org/wiki/Template:SPARQL2 2 on the OpenStreetMap wiki? Following the suggestions at https://community.openstreetmap.org/t/openstreetmap-wiki-template-equivalent-to-wikidata-template-sparql2/4762 the name could be something like WikidataSPARQL. I also think the "Run it" links should give a hint that's directly on Wikidata (maybe "Run in on Wikidata" ?) So even at a minimal level, users could not be confused with the target point not being Sophox (which by the way, do allow glue data from more places, and to access Wikidata would be on federated mode; so Sophox really deserves to be the default endpoint!). The reason to have a direct endpoint to Wikidata SPARQL is to allow easy copy-and-paste without changes and is for performance (in case the query is only Wikidata). I could try to copy the template from Wikidata, however this is relevant enough to at least have more people think that if we should do this and, if should, how to name the things. Also, maybe good idea to ping people from Sophox (not sure about their Wiki names). Thanks! EmericusPetro (talk) 14:51, 29 October 2022 (UTC)

Where and how it would be used? In general templates can be created (though mention source when copying in edit description), but I am not seeing how this one would be used. Where you are planing to use it? @EmericusPetro: Mateusz Konieczny (talk) 18:17, 29 October 2022 (UTC)

@Mateusz Konieczny: Great question! I already some early drafts of pages at User:EmericusPetro/sandbox (these might not become pages at all) which currently I'm using <syntaxhighlight lang="sparql"></syntaxhighlight> and also I'm looking to create ones very specific to OpenStreetMap itself, such as ones based on OpenStreetMap local chapter (Q56695738) for queries like https://query.wikidata.org/#SELECT%20DISTINCT%20%3Fitem%20%3FitemLabel%20%20WHERE%20%7B%0A%20%20%3Fitem%20p%3AP31%2Fps%3AP31%2Fwdt%3AP279%2a%20wd%3AQ56695738%20.%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%22.%20%7D%0A%7D%0A. In a matter of a week or less I should have far more examples, and also it is necessary to do some edits on Wikidata, but I already could give an early idea. Later I'm likely to propose ways to actually update data tables based on the queries (Wikimedia uses more than one strategy, one even with bot accounts, others use Tabular data on Commons), but this would be another topic and is not as simple as this template. But in any case, the data already on Wikidata (even for concepts related to OpenStreetMap itself) would both be reusable here in the Wiki but also in other tools. EmericusPetro (talk) 21:26, 29 October 2022 (UTC)

That looks better fitting https://www.wikidata.org/wiki/Wikidata:OpenStreetMap as it seems about maintaining Wikidata copy of data that is already stored elsewhere in a better quality Mateusz Konieczny (talk) 11:32, 30 October 2022 (UTC)

(For everyone) Also, while it is possible to sort of emulate the effect, with a template it would be possible to encode the content to make them clickable on external URLs in a central point. For example, since these queries tend to be relevant (if not for something related to OpenStreetMap, at least for pages of projects), it would make sense to have a download to CSV direct link. Wikidata does have this format and JSON, but it would start to get very repetitive and someone like me forgot to update all the links. I didn't stop to think better about it, but it wouldn't be strange if even part of what's today's Tags/Keys pages could have one specialized Widget for users clicking to download whatever is on Wikidata (obviously some will timeout, but the average case is likely to be viable). One of my sandbox drafts at https://wiki.openstreetmap.org/wiki/User:EmericusPetro/sandbox/List_of_Wikidata_to_OpenStreetMap_tag_or_key already can map OSM to Wikidata Properties (note, not Wikidata Q Items; these allow to fetch far more data from Wikidata), so while not perfect as handcrafted version, maybe could be possible to generalize some downloads on what's on Wikidata to put on OSM Wiki map feature, but this would be better on dedicated template after this one (which could be minimalist, only with download links, without average person need to know SPARQL). EmericusPetro (talk) 22:31, 29 October 2022 (UTC)

@EmericusPetro: We already have {{SPARQL}}, which is used primarily in SPARQL examples but targets Sophox rather than the Wikidata Query Service. (Sophox federates with WDQS but not the other way around.) I'd suggest that queries targeting WDQS directly are a better fit for wiki pages on Wikidata that are useful beyond the OSM community, but federated queries are a good use of {{SPARQL}}. Nevertheless, you could add a parameter to this template to customize the endpoint. This would also be useful for other OSM-powered SPARQL endpoints, such as LinkedGeoData. – Minh Nguyễn ^💬 03:28, 31 October 2022 (UTC)

@Minh Nguyen: Your suggestion to add it as a parameter (instead of creating another template) makes more sense to me than my proposal! Also, thank you to inform about the http://linkedgeodata.org/ as an endpoint that does use OpenStreetMap data. In any case, I just commented it also on talk page https://wiki.openstreetmap.org/wiki/Template_talk:SPARQL. Sophox and WDQS uses the same pattern for URL, so in this case is viable simple parameter replacement. Not sure the timeline you here close the discussions as solved, but I'm already okay about {{SPARQL}} being customized. EmericusPetro (talk) 21:25, 31 October 2022 (UTC)

Resolved: answered Mateusz Konieczny (talk) 07:05, 3 November 2022 (UTC)

Proposal to remove data item for technical reasons

Posting here to make people aware - either way it goes it is important to make people here aware of it

See https://github.com/openstreetmap/operations/issues/764

@Firefishy: (it would be nice to make affected people aware of it - have you notified iD author?)

Is there anyone here able to help with solving technical problems mentioned there?

Mateusz Konieczny (talk) 11:22, 30 October 2022 (UTC)

@Firefishy: Disabling this feature will break at minimum multilingualism for concepts very specific to OpenStreetMap which already are not on Wikidata (the places names themselves are there). Even without numeric identifiers for OpenStreetMap keys or tags (which would be desirable, but is not ready), the functionality seems to be already has been used for years, as described on https://wiki.openstreetmap.org/wiki/Data_items (note the the Q's and in special P's pages such as https://wiki.openstreetmap.org/wiki/Property:P16). I actually am sure this extension is likely to be harder to maintain than the average PHP one, but even the migration plan to remove this would be painful to discuss (both for data migration and additional customized tools to make it). But the complaint about maintenance is still valid, because is hard so it is better to have more people engaged. Maybe you could try to point to people in GitHub the issue the problems with version upgrades that this extension makes it harder? Or server load issues? I saying this because I also keep servers running and from time to time I have to people around specific features that make operation harder, and this works. —Preceding unsigned comment added by EmericusPetro (talk • contribs)

Resolved: people watching this page were notified Mateusz Konieczny (talk) 07:04, 3 November 2022 (UTC)

Kaart tracks deletion request

Some files used here and under deletion request on Wikimedia Commons maybe may be rescuable.

See https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Files_uploaded_by_Garylancelot - some files may be rescuable, maybe someone wants to spend effort on that (though typical use like https://wiki.openstreetmap.org/wiki/WikiProject_Bosnia_and_Herzegovina#Kaart_Mapping seems to not be really important) Mateusz Konieczny (talk) 17:48, 18 November 2022 (UTC)

Some may be eligible for reupload on OSM Wiki Mateusz Konieczny (talk) 17:54, 18 November 2022 (UTC)

Proposed MediaWiki:Uploadtext changes

• Clarify what can be uploaded to Wikimedia Commons and recommend uploading screenshots of free software there: https://wiki.openstreetmap.org/w/index.php?title=User:Mateusz_Konieczny/notify_uploaders/commonify&diff=2397830&oldid=2397826
• Strengthen recommendation that files should be uploaded there:: https://wiki.openstreetmap.org/w/index.php?title=User:Mateusz_Konieczny/notify_uploaders/commonify&diff=2397831&oldid=2397830

Overall, I would strongly encourage Commons over OSM Wiki uploader. We continue to drown in problematic images, our upload interface is broken. Commons is not ideal but have multiple people working on improving this things, while we have less than 1.

Maybe have a big section "our upload interface is terrible, our file handling is terrible, please please please use Wikimedia Commons instead".

See "I'm gonna have to use the wikicommons uploader in the future, because the one here is useless. I had added a description, and I always tick "my own work" thing, yet I always have to go in afterwards and add it manually."

Mateusz Konieczny (talk) 08:41, 23 September 2022 (UTC)

Asked on https://wiki.openstreetmap.org/wiki/Wiki:Requests_for_administrator_attention#MediaWiki:Uploadtext_changes - for now without reaction. Maybe I will ping sysops in month or two Mateusz Konieczny (talk) 07:25, 29 October 2022 (UTC)

@Mateusz Konieczny: Sorry for the delay. I've implemented your suggestions, sort of. Instead of detailing things like editors' licenses in this box, I linked to Wikimedia Commons#Project scope, where you can help refine the guidance on what to upload to Commons. By the way, it is legal and acceptable to upload a screenshot to Commons that contains copyrighted background imagery, as long as it meets the fuzzy legal standard of de minimis. In my experience, most screenshots of editors here do meet that standard; it's only the standalone screenshots of, say, Bing aerial imagery itself that would fail this test. – Minh Nguyễn ^💬 02:56, 15 November 2022 (UTC)

Resolved: Mateusz Konieczny (talk) 07:23, 15 November 2022 (UTC)

Why not Commons for OSM editors?

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

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

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

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

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

Note: relevant page is MediaWiki:Uploadtext Mateusz Konieczny (talk) 06:09, 14 September 2022 (UTC)

Can you license OSM-based map as CC0?

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

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

Resolved: edited file description page Mateusz Konieczny (talk) 07:29, 29 October 2022 (UTC)

Revert renaming of API 0.7 to 1.0

In https://wiki.openstreetmap.org/wiki/User_talk:Erkinalp I discussed with a user to revert their renaming to the API 0.7 page to https://wiki.openstreetmap.org/wiki/API_v1.0. Unfortunately, they’re unable to do it on their own and asked for admin support to take over. Could you help out please? Mmd (talk) 07:21, 20 November 2022 (UTC)

Resolved: --Tigerfell  (Let's talk) 13:15, 20 November 2022 (UTC)

Thanks! I also fixed a few remaining references to API 1.0 on the wiki page itself. Mmd (talk) 13:32, 20 November 2022 (UTC)

By the way, this wiki editor seems a bit broken. I have no idea, why it added my comment to the next section. Mmd (talk) 13:33, 20 November 2022 (UTC)

Can we keep this logo? If yes - then why?

Are we allowed to keep https://wiki.openstreetmap.org/wiki/File:Aller-ElbeLogo.jpg or should we delete it as unfree and not really needed?

If we keep it - why exactly we are allowed to do this?

Mateusz Konieczny (talk) 21:15, 22 September 2022 (UTC)

I marked that file for deletion Mateusz Konieczny (talk) 06:37, 29 September 2022 (UTC)

File become deleted Mateusz Konieczny (talk) 13:08, 24 November 2022 (UTC)

Automate obvious part of "Image superseded by Wikimedia Commons"

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

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

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

Following would be still handled manually

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

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

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

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

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

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

I have script that I am using and allows much faster processing of images but for various reasons manual overview is still needed, so I am withdrawing this bot idea. In effect I will edit OSM Wiki manually with special custom editor. Mateusz Konieczny (talk) 21:40, 22 November 2022 (UTC)

Improving the Beginners' guide

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

Resolved: seems that it can be archived now Mateusz Konieczny (talk) 11:17, 4 December 2022 (UTC)

RDF dump of OpenStreetMap Data Items

I'm interested in starting to use Protégé against Data Items, however I'm curious how to mass download them without looping https://wiki.openstreetmap.org/wiki/Special:EntityData/Q2.ttl until https://wiki.openstreetmap.org/wiki/Special:EntityData/Q20000.ttl (plus the Ps). How this could be done now?

Also, since this might lead later to document how people can use it (and Protégé is quite point and click) it might be a good idea to have regular dumps (if not daily, then weekly, at least while Wikibase extension is installed) so people can use some pre-built version. Anyway, the Data Items (which is not the full OSM data) likely be a small file size, and generating the triples directly from the server might be relatively quickly. The way Protégé works also allows it to set up an .owl file that imports several URLs (first it try check catalog-v001.xml for local copies), so people can use as base project for other things.

As last question (not really a request, just curious): does there exist any known standalone tool/script to convert existing .osm or .pbf (the OpenStreetMap data itself) to a RDF as close as the Data Items format (e.g. assuming will be merged into the sabe triplestore)? I might create one exporter anyway by looking at the documentation, but already existing tools might help the first tests.

--EmericusPetro (talk) 06:00, 14 November 2022 (UTC)

@EmericusPetro: Sophox uses Blazegraph to download this Wikibase instance's items, though I don't know exactly what endpoint it hits. [9] Sophox and LinkedGeoData store OSM data quite differently from each other and provide different functions atop this data. – Minh Nguyễn ^💬 08:48, 14 November 2022 (UTC)

@Minh Nguyen: If we could get this Data_items/Technical_Site_Configuration#TODO (the dumpRdf.php part) up and running in the Wiki would help a lot 🙏. As an alternative, I've created not-so-smart, the User:EmericusPetro/sandbox/Poor_mans_OpenStreetMap_Data_Items_dumper, however with a 5s delay it took around 28 hours to generate a 10mb zip file. --EmericusPetro (talk) 16:31, 16 November 2022 (UTC)

@EmericusPetro: This looks like something the operations or sysadmin team would need to be involved with – someone with access to cron on the server that runs the wiki. I'd recommend opening an operations issue and tagging Yurik on it. I wouldn't be surprised if it gets held up by the ongoing discussion about removing Wikibase, but at least it would be on the backburner in case that issue gets resolved favorably. – Minh Nguyễn ^💬 18:00, 16 November 2022 (UTC)

@Minh Nguyen: done at https://github.com/openstreetmap/operations/issues/779 --EmericusPetro (talk) 10:11, 17 November 2022 (UTC)

Sohpox downloads OSM data from various sources, e.g. minutely updates stream, OSM Wiki API for data items, etc. Sophox indeed needs to be migrated to the new server. I need $150/month to run it, and set up a 501c(3) via OpenCollective for that. Once I have enough for the first two months, I will migrate Sophox to the new hardware, bring it up to date, etc. Also, would be awesome to get more developer help with maintaining it at GitHub. --Yurik (talk) 05:10, 16 November 2022 (UTC)

@Yurik: Great! Just to comment: the use case for semantic reasoning is more close to how formal ontologies are used on bioinformatics (TBox, download OWL and run on small amounts of data) than Wikidata (TBox + ABox, public SPARQL service). Even in the unrealistic scenario of central server always have consistent/coherent ontology all the time, a far smaller TBox+ABox still can't deal with reasoner turned on because CPU usage would skyrocket just to recompute all possibilities, including ones user not care at the moment (but the server could know user don't care). So I do agree on the importance of a public server such as Sophox makes everyone's lives much easier, and that it is technically feasible that Wikibase store a larger Tbox, however semantic reasoning is not viable at server side.
So, performance-wise, one simple way for people not to get into trouble when not aware of what is talking too much processing power is selectively load small Tbox (Data Items, other rules about the data) and ABox (load small world regions per time, or global, but selected features). In this aspect, having standalone scripts to convert data to a known RDF format make such uses feasible.
But yes, obviously it makes sense to be compatible with the exact same schema (which by the way, wonderful work!). --EmericusPetro (talk) 16:31, 16 November 2022 (UTC)

Thanks everyone! This was solved some time ago, can be archived --EmericusPetro (talk) 06:10, 22 December 2022 (UTC)

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

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

Jeisenbe Can you give an example of how it is meant? I am no longer a friend of taglists because a lot of information is lost.--geozeisig (talk) 06:49, 27 February 2020 (UTC)

Well, I thought that changing the underscores to dashes would fix the problem, but now it does not appear to be working for Template:Map_Features:aerialway. Perhaps the problem is with all png files? See https://github.com/taginfo/taginfo/issues/201 and https://github.com/taginfo/taginfo/issues/223 --Jeisenbe (talk) 08:01, 28 February 2020 (UTC)

Thank you for finding the reason of not displayed pictures in Taginfo/Taglists. I noticed this behavior some time ago also for the historic=* table, see my question there at the discussion page: Talk:Key:historic#Taglist_rendering_pic_not_displayed_e.g._for_historic.3Dcastle_wall. Okay, i could help to fix it, but can't tell when i have time for it. By the way, i also struggle a bit with the newer Taginfo/Taglists system, because for some reason i can't see the preview (edit:"Show preview"-function button). The error message says LOADING TAG LIST... (If you do not see this tag list, you need to enable Javascript). Is there something i have to configure on my machine (Javascricpt seems activated for the used browser - firefox), or is this a general issue? Without working edit:"Show preview"-function i wouldn't want to switch to the taglist system. --MalgiK (talk) 11:03, 27 February 2020 (UTC)

Re: "The error message says LOADING TAG LIST..." - I see this sometimes when I have a bad internet connection, but usually if I hit the "preview" button again, it will show. I agree that it is annoying to rely on Javascript rather than having the table pre-rendered. Perhaps someone can fix this technically.

Interesting, i think i'm trying it when having a good enough internet connection and i can see the delayed situation while loading an "normal" article page , but it never shows the Taglists after hitting the "preview"-button [10]. --MalgiK (talk) 08:07, 1 March 2020 (UTC)

I do like that the descriptions and images are now the same on Map Features and on the wiki pages for each tag, with this system, and this means that they are more likely to be correct and up-to-date. --Jeisenbe (talk) 04:05, 28 February 2020 (UTC)

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

Redesign of page not found message

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

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

This is a work in progress:

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

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

 – Minh Nguyễn ^💬 23:53, 17 October 2020 (UTC)

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

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

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

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

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

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

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

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

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

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

@Minh Nguyen: - seems done now, right? I will mark it as solved and archive after some time but feel free to undo this Mateusz Konieczny (talk) 19:52, 13 September 2022 (UTC)

@Mateusz Konieczny: Thanks for the reminder. I haven't implemented these changes yet and particularly would like to implement the boilerplate at some point. Unfortunately the boilerplate isn't working correctly at the moment – the last time I tried using it, it expanded the template the wrong number of times, resulting in some syntactic cruft I had to delete. Do you think it would be a good idea to deploy the presentational changes without the boilerplate for the time being? – Minh Nguyễn ^💬 04:09, 14 September 2022 (UTC)

@Minh Nguyen: Hi, not tragic, but for information: There is a LUA error on MediaWiki:Newarticletext in combination with :* in key name, e.g. with prefixes like Key:ref:* --Chris2map (talk) 15:02, 26 November 2022 (UTC)

@Chris2map: Thanks, fixed. Key:* is a bit of an oddball, being a redirect that will (hopefully) never have a data item of its own. – Minh Nguyễn ^💬 01:15, 27 November 2022 (UTC)

Polymorphic image

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

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

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

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

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

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

Can we archive this? --Chris2map (talk) 16:09, 3 December 2022 (UTC)

Delete sites diet:* and DE:Key:diet:*

Could someone please delete the pages Key:diet:* na DE:Key:diet:*? I would like to move the pages describing the prefix to them. -- Lenochod (talk) 20:29, 13. January 2023 (UTC)

I moved the pages and deleted the others. What should happen to the two data items ERROR: Invalid ID and diet (Q227)? --Tigerfell  (Let's talk) 20:04, 14 January 2023 (UTC)

The initial setting by Yurikbot in 2018 was:

• Item:Q227 (diet) for Key:diet
• Item:Q5719 (diet:) for Key:diet:
• Item:Q6056 (diet:*) for Key:diet:*

Since, as far as I can tell, the longest and most information was maintained on the "Key:diet" page, and has always been treated as a prefix there, I would consider the item associated with that original page representative: That would then be Item:Q227. The other two would I empty and put a redirect to Q227. --Chris2map (talk) 21:38, 14 January 2023 (UTC)

Only data administrators can redirect items. I can just protect and delete them. In addition, I do not see how I should change permanent key ID (P16). That limits my possiblilties to delete the items Q227 and Q5719. If nobody objects I would do that then. --Tigerfell  (Let's talk) 23:08, 20 January 2023 (UTC)

I removed ID P16 from Item:Q227 so we can set a new one. --Chris2map (talk) 23:16, 20 January 2023 (UTC)

@Tigerfell: Does this procedure require data admin rights: Special:RedirectEntity? I cannot or don't want to test it. --Chris2map (talk) 16:26, 23 January 2023 (UTC)

Yes, it does. You can see that at Special:UserGroupRights. MediaWiki lists all permissions there for every user group. Additionally, I tested it and received "Permission Denied" when redirecting Item:Q22152 to Item:Q22151. --Tigerfell  (Let's talk) 21:53, 24 January 2023 (UTC)

Okay I set a new one and deleted the other data items. --Tigerfell  (Let's talk) 22:08, 24 January 2023 (UTC)

Undo all

After doing test/practise edits, is ther an undo all/cancel button, and if not can i sugget adding one Intercity225 (talk) 10:42, 13 February 2023 (UTC)

@Intercity225: Use Sandbox for test edits. Wiki pages have history and old versions can be restored. See https://meta.wikimedia.org/wiki/Help:Page_history for documentation that almost entirely applies also to OSM Wiki Mateusz Konieczny (talk) 14:46, 13 February 2023 (UTC)

Resolved: Mateusz Konieczny (talk) 19:02, 16 March 2023 (UTC)

Disclaimer

https://wiki.openstreetmap.org/wiki/Disclaimer is linked in footer and self-describes itself as nonsense

It would be nice if Someone(TM) would solve the problem claimed to exist there Mateusz Konieczny (talk) 19:02, 16 March 2023 (UTC)

Problem is that a user thought it might be helpful to explain the limitations of OSM's data quality and then years later 1 (!) other user thought the page was rubbish and stated that on top in a red box.

Do you have a suggestion what to write on this page? The content of Wikipedia's disclaimer seems to be pretty similar except that the page talks about OSM but not the wiki. --Tigerfell  (Let's talk) 23:04, 16 March 2023 (UTC)

@SimonPoole: - why you claim that this "content of this page is misleading, if not outright nonsense"? Which part is problematic?

Personally it seems to me that it is mostly pointless as disclaimer on OSM Wiki should be rather about OSM Wiki quality - but what is nonsense here?

Mateusz Konieczny (talk) 20:31, 17 March 2023 (UTC)

I'm probably guilty of mentioning this page at the Community discussion :). While Simon should have minced some words in this tag, his point is mostly clear: this page is mostly pointless as it is now, and should be (mostly) about OSM Wiki quality.
While I could be the Someone(TM) to address this, I'd like to have a starting point for a rewrite -- shall we reuse some stuff from the Wiki page? Should we summarize and point to "the OSMF Terms of Use for current terms of use, and ODbL 1.0 for data licence information and CC BY-SA 2.0 for the contents of this wiki." as suggested by Simon? All of those are sorts of disclaimers, for various aspects of the project. Duja (talk) 11:29, 20 March 2023 (UTC)

Maybe just link to different places? For info about Wiki quality see Wiki page, for XXX see LINK...? To avoid repeating the same content? Mateusz Konieczny (talk) 13:58, 20 March 2023 (UTC)

I had in mind, like, having four short sections summarizing different aspects (Wiki disclaimer, Map contents disclaimer, Legal disclaimer, License) and pointing to long versions thereof using Template:Main. Duja (talk) 14:03, 20 March 2023 (UTC)

Mateusz Konieczny, SimonPoole -- done [11]. Feel free to tweak further. Shall we remove the tag now? Duja (talk) 09:11, 24 March 2023 (UTC)

Resolved: Thanks Duja! If SimonPoole thinks that problem is not fixed, feel free to add specific disclaimer on disclaimer page or change the page directly Mateusz Konieczny (talk) 17:42, 30 March 2023 (UTC)

Spam account

Since we don't have an equivalent of Wikipedia:WP:ANI (thank God): there is a spam account TheNewsBase (on osm, edits, contrib, heatmap, chngset com.) that should be blocked by a kind admin. Duja (talk) 11:16, 22 March 2023 (UTC)

We have Wiki:Requests for administrator attention :) Though without WP:ANI drama. Mateusz Konieczny (talk) 08:18, 23 March 2023 (UTC)

That page is supposed to be unfindable, I guess? :) May I kindly request that it is linked from the sidebar, instead of things like OSM Blogs and Merchandise, last updated in 2021? Duja (talk) 09:08, 24 March 2023 (UTC)

Resolved: Blocked Mateusz Konieczny (talk) 17:45, 30 March 2023 (UTC)

RFC: Two new extensions for the wiki: Log in via openstreetmap.org and vote via a GUI

Hi everybody,

I wrote two small MediaWiki extensions for this wiki: one to let you log in via your OSM account and one to provide an easy to use in-wiki GUI for proposal voting.

I also set up a small demo wiki so that you all can try both extensions out:

https://demo-wiki.push-f.com/

You can leave your feedback using both extensions on the demo wiki, or alternatively here.

(I made the same announcement on the talk@ and tagging@ mailing lists and the community forum).

Cheers, --push-f (talk) 09:58, 13 October 2022 (UTC)

Hey, nice work! But couldn't this also be done via gadgets? By the way, I also like your minimal Vanilla JS code for the proposals list. Bkil (talk) 23:21, 6 November 2022 (UTC)

Resolved: seems that everyone who monitors this page was notified and others will not notice this posting, so it can be archived soon Mateusz Konieczny (talk) 21:08, 2 January 2023 (UTC)

Prefix pages do not create automatic Category links

When converting Key:drink to the Key:drink:* prefix, I noticed that the converted page does not automatically create a link to the categories in the footer of the page.. For comparison: Pl:Key:drink vs DE:Key:drink:*. -- Lenochod (talk) 10:09, 20. November 2022 (UTC+1)

Categorization has just been added for prefixes. Please try and let me know if there is any issue. --Chris2map (talk) 14:46, 26 November 2022 (UTC)

Also added to category page by group? -- Lenochod (talk) 13:42, 7. December 2022 (UTC)

What do you mean by "page by group"? Look for instance on Key:drink:*. There is Category:Key descriptions for group "food and beverages". Do you mean that or missing something? (BTW are you back to future? There is something strange with your date of the comment.) --Chris2map (talk) 21:55, 7 December 2022 (UTC)

"page by group" for Key:drink:* is Category:Food and beverages.

The day contains a typo, fixed. -- Lenochod (talk) 20:20, 9. December 2022 (UTC)

@Chris2map:Also added to Category:Namespaces? -- Lenochod (talk) 20:26, 9. December 2022 (UTC)

Category "page by group" now is implemented. --Chris2map (talk) 22:19, 9 December 2022 (UTC)

@Lenochod: Before adding Category:Namespaces I want to question, if we should take Category:Key prefixes and Category:Key suffixes and put these below Category:Namespaces ? --Chris2map (talk) 21:26, 10 December 2022 (UTC)

Creating pages Category:Key prefixes and Category:Key suffixes is a good idea. I'm not a programmer, so I can't help with scripts. But I can help with the creation of these pages for other languages as well. -- Lenochod (talk) 17:52, 14. December 2022 (UTC)

Resolved: I have created English pages for prefixes and suffixes, automatic links on these pages works, it can be archived. -- Lenochod (talk) 10:24, 18. January 2023 (UTC)

Documenting the limitations of OpenStreetMap

Hey all, I just created Limitations as an attempt to document the limitations of OpenStreetMap. You are more than welcome to leave feedback here or on the talk page :) I am also interested in any other limitations you can think of, that aren't listed on the page yet.

Cheers, --Push-f (talk) 15:26, 9 December 2022 (UTC)

I edited this page a bit Mateusz Konieczny (talk) 15:43, 9 December 2022 (UTC)

Thank you, Mateusz! --push-f (talk) 16:09, 9 December 2022 (UTC)

I added a comment to the discussion page. Good idea overall (thumbs up emoji). --Adamant1 (talk) 05:35, 10 December 2022 (UTC)

Good job  ! — Koreller (talk) 10:22, 11 December 2022 (UTC)

I really liked this page! Thanks! Was this page inspired on the WikiProject Limits of Wikidata?
Anyway, some quick recent discussions on some topics. About the Limitations#Tags are just strings (marked as Permanent limitations), I would invite everyone aware of these points to comment on https://community.openstreetmap.org/t/producing-a-validated-osm-dataset/7106 . At least part of the issues (like enforce strict predictability; maybe discart what fails to validate some rule) could be done regardless of the initially added data on OpenStreetMap, so some schema could actually be enforced at some distribution of OSM data. And about the Limitations#No_persistent_IDs (marked as Current limitations'), there's also one discussion here https://community.openstreetmap.org/t/persistent-and-stable-identifiers/6819 . --EmericusPetro (talk) 04:19, 23 December 2022 (UTC)

Thanks, I'm glad you folks find the page useful :)

I actually only found out about that WikiProject after creating wikidata:User:Push-f/Wikidata:Limitations.

Note that I also created such a page for MediaWiki at mw:Limitations (although that page is still much more rough than the pages I created for OpenStreetMap and Wikidata).

Btw I just created Limitations/User interface to document the biggest current limitations of the https://www.openstreetmap.org user interface. You're all welcome to expand the page :)

--push-f (talk) 23:23, 26 December 2022 (UTC)

Resolved: seems that everyone who monitors this page was notified and others will not notice this posting, so it can be archived soon Mateusz Konieczny (talk) 21:08, 2 January 2023 (UTC)

A map for tourism activities?

Hello, I started a list of "maps" that we can use to see tourism attractions like museum, castle, waterfall, viewpoint, zoo, park, etc. Please consider adding other "maps" you know in the Tourism article, section 'Maps'. --Binnette (talk) 11:57, 18 December 2022 (UTC)

Thanks for doing that. I didn't even know any of those maps existed. --Adamant1 (talk) 12:22, 18 December 2022 (UTC)

Resolved: seems that everyone who monitors this page was notified and others will not notice this posting, so it can be archived soon Mateusz Konieczny (talk) 21:07, 2 January 2023 (UTC)

The pages links to the category redirect site

Some wiki pages automatically link to the redirect page category. For example:

• Zh-hans:Highways with {{Feature links to Category:Zh-hans:Highways instead Category:Zh-hans:道路.

How to best solve this problem?

• DE:Education_features with {{Feature links to Category:DE:Education_features instead Category:DE:Bildung. This issue was caused by a merge Category:DE:Education_features to Category:DE:Education. But the Category:DE:Bildung page already contains site DE:Education.

Can it be solved other than by renaming the page? -- Lenochod (talk) 20:20, 2. January 2023 (UTC)

The Template:Feature just checks if there is a category with the same name as the page's name of the feature page. Also, in language namespaces other than English, it can only check if there is a language namespace version of the page (e.g. Category:ES:FeaturePageName instead of Category:FeaturePageName). Often those pages are redirects to translated pages with a translated page name. But the template cannot recognize if there is a translated page an the linked page is just a redirect, AFAIK. – Examples: Feature page "ABCDEFG" can link to "Category:ABCDEFG"; "DE:ABCDEFG" to "Category:DE:ABCDEFG"; "Zh-hans:ABCDEFG" to "Category:Zh-hans:ABCDEFG" --Chris2map (talk) 20:16, 2 January 2023 (UTC)

I was wrong! You can use the parameter "title=" with {{Feature}} to set the translation used in the category name. See e.g. DE:Aeroways. --Chris2map (talk) 20:22, 2 January 2023 (UTC)

Wow, |title= is a simple and functional choice. Thanks. -- Lenochod (talk) 7:25, 6. January 2023 (UTC)

Resolved: I used it, is functional, it can be archived -- Lenochod (talk) 7:28, 6. January 2023 (UTC)

Correct name for page suffix and prefix?

What is the correct page name for prefix and suffix? I use the name key:* for the prefix. But now I came across redirect Key:diet:* to Key:diet.

I haven't used the suffix yet, but I'll know when I edit a page. -- Lenochod (talk) 12:29, 7. January 2023 (UTC)

The current naming convention is Key:prefix:* and Key:*:suffix, see Proposal:Documentation of key prefixes & suffixes. --Chris2map (talk) 21:53, 7 January 2023 (UTC)

Resolved: I used it, it can be archived. -- Lenochod (talk) 20:31, 13. January 2023 (UTC)

Categorizing "Mismatched ..." in subcategories for "default English namespace"

The Category:Mismatched image is pretty filled with entries from many language namespaces. In order to get more usability I enhanced the module "DescriptionFromDataItem" to use categories with language namespaces, e.g. Cs:Mismatched image, DE:Mismatched image, etc. For now, it is in the sandbox version of the module (permalink). For testing see Template:ValueDescription/Sandbox/doc. Is there any support, annotation or objection to my suggestion? --Chris2map (talk) 23:29, 20 February 2023 (UTC)

I changed my suggestion so that there won't be any change or difference to the existing categorization of data item issues. But in addition there will be one subcategory per issue which will only contain the pages from the default English namespace; see — Category:Mismatched status in default English namespace — Category:Mismatched onNode in default English namespace — Category:Missing data item in default English namespace. — So you could focus on fixing mismatched statuses or other mismatches on the english tag description pages. For testing see Template:ValueDescription/Sandbox/doc and Module:DescriptionFromDataItem/Sandbox (permalink). --Chris2map (talk) 15:37, 24 February 2023 (UTC)

The topic seems to arouse little interest. Since I use the categories regularly, the adjustment would be a help for me. Since I am not changing any of the existing categories with my current proposal, but only making an addition, I would and will start implementing the adjustment. The only thing I would like to ask is purely linguistic: Is the naming of the new categories so easy to understand and correct English? I have tried to keep the names as short as possible and as verbose as necessary. --Chris2map (talk) 17:41, 28 February 2023 (UTC)

What word "default" changes there? Is there difference between default Eglish namespace and English namespace? Mateusz Konieczny (talk) 18:31, 28 February 2023 (UTC)

There is no difference, of course. I wanted to emphasize that is not related to English speaking regions specifically, but to all. How about skipping the "English" and label it "Category:Mismatched onNode in default namespace" and "Category:Missing data item in default namespace"? --Chris2map (talk) 19:01, 28 February 2023 (UTC)

Not really sure :/ Maybe just put and explanation in the category description? And for categories itself - if you need them and noone is protesting: go for it and create them Mateusz Konieczny (talk) 09:42, 2 March 2023 (UTC)

Thank you for your notes! Since the tag pages that should be listed in the additional categories do not start with "EN:" but are actually in the default namespace, I will name the categories accordingly without the word "English" but "default". --Chris2map (talk) 17:02, 2 March 2023 (UTC)

Resolved: --Chris2map (talk) 19:33, 16 March 2023 (UTC)