I see the point that breaking a signature breaks the tool. But I don't
think it will be a big problem myself.

A lot of comments. There is something to say for changing the signature, for leaving the signature and even for adding a new signature, but it is all depending on the circumstances. I would trust the people editing to do the right thing, if in doubt, you can always check the history.

I have learned to never say 'all' on Wikipedia :-), but all topic-related village pumps, and the villagepump itself (de kroeg) are in there, so this should at least cover the Wikipedia namespace, which I think is the main part where there can be confusion. For the rest, yes, you understood me correctly.

In T304753#7807870, @ppelberg wrote:

In T303493#7789747, @Akoopal wrote:

A very simple approach, that is always good as a fallback, is magicwords/variables where the community can steer the software, so explicitely marking a page as discussion/non-discusssion. That can be then hidden in templates, for example for nl-wiki in [[w:nl:Sjabloon:Kroegentocht]], which is added to the relevant pages anyway.

@Akoopal can you share more about the "...be then hidden in templates..." part? What wikitext is being hidden in the Sjabloon:Kroegentocht template? What does this wikitext do to the pages it is added to?

A very simple approach, that is always good as a fallback, is magicwords/variables where the community can steer the software, so explicitely marking a page as discussion/non-discusssion. That can be then hidden in templates, for example for nl-wiki in [[w:nl:Sjabloon:Kroegentocht]], which is added to the relevant pages anyway.

It would be good if the text can be customized. There are pages which act like discussion pages, but are also request pages, for example most subpages of [[w:nl:WP:VP]] where it is good to have instructions. Secondly, those pages work with comments starting on level 3 under a level two header, where level two might just be new/done/not done. Would be good to accomodate there.

Hmmm, I now noticed your tool is not working the same. The power of erwin85's version was that it included subcategories in the search where you could also indicate how deep it would look. By testing your version a bit, I seem to get only articles from the main category, not from sub-categories.

Superyetkin: willing to bring the patches to the erwin85 tool itself, I can add you as maintainer? Maybe you are willing to look at other tools as well? I know they use the same basic structure, I myself would be very interested to have related changes working again.

Via a question I noticed the same via nl-wiki:

Ok, clear. But if there are signatures in a section, and there is not a signature at the end, that should at least be safe?

I want to make again a suggestion I have given above, but seems to be missed. Often the unsigned comment is the last comment. I think that that case should be much more easy to recognize, as it will be followed by a header, so it is clear that it is the end of the discussion. Doesn't it make sense to at least always put a reply button at the end of the discussion?

Thanks for reporting this one. First of all, we tested a bit on the talkpage of the linked page on nlwiki, it seems that the reply tool is triggered by the time stamp. If you just add the timestamp behind the template, there is a reply button. However, if you use the template functionality to add the date however, there is a reply button, but small as the template text, and it doesn't work. See the talkpage.

For the Dutch wikipedia there isn't a draft namespace, but it is common for people to create draft articles as subpages of their userpage, where 'Kladblok' is the most common one, and a link to it has been provided in the interface. So for there it would needs enabling on the User: (Gebruiker:) namespace. As Krinkle already commented that should not pose any problems.

How long are thumbs cached? Instead of changing all the pages, isn't it easier to just harvest all the images on these pages, make a wikipage containing all those images, and visit them so the thumbs are created (in batches of course). Then the images are created without having to change all the pages.

Looks to be fixed

To get access to toolforge, see https://wikitech.wikimedia.org/wiki/Help:Getting_Started

It looks to be working again, sorry I didn't respond before.

Checked myself now, you are definitely right for the last running version. Maybe that changed indeed over time.I have used this one a lot a couple of years ago, and much less in the last years.

It had. The default google api included a search box with the map widget.
This is jsut about typing in for example 'Amsterdam' and from there zoom in
to the appropriate location. Not sure if this API supports it as well?

What I am missing at the moment is a search-box to quickly jump to a
location.

I see:

In T134814#3679386, @Deskana wrote:

In T134814#3677903, @Akoopal wrote:

The example I provided, https://nl.wikipedia.org/wiki/Lijst_van_rijksmonumenten_in_Zaandam?veaction=edit still takes ages, and in firefox, I get the unresponsive script popup. So for these lists it is still far from working.

Indeed, it takes ages for me too. This is why the task remains open, and why I added to the description that "Improvements were made to this which has lessened the problems significantly, but it could still be improved further."

The example I provided, https://nl.wikipedia.org/wiki/Lijst_van_rijksmonumenten_in_Zaandam?veaction=edit still takes ages, and in firefox, I get the unresponsive script popup. So for these lists it is still far from working. And Zaandam is even a relative short list.

I have given it thought, and didn't start a discussion on this, as I expect it will have more resistance as people are to much used to it and not sure it is worth it. It's a pity it has to work this way.

Thanks all, very quick turnaround. Works for me again.

From irc:

tail -10000 access.log | awk '{print $7}' | sed 's/\?.*$//' | sort | uniq -c | sort -rn | less

I made the link blue again in public_html/inc/footer.inc.php

With the current project to phase out precise, this should get more focus.

This has now been implemented, there is now an option to 'hide category edits' same way as others.

False alert, I didn't see any reports in the contributions quickly, and I saw a nomination that was not reported to the creator, but that must have been a one off, looking better I just see the bot doing it's job.

I thought this was already closed, but this issue is resolved already.

If I understand you correctly you want to just always hide wikidata and category edits? I do think it is usefull to see the wikidata-edits, marked as such, and similar to see the category edits. Do you know which rc_type number the category changes gets? Then it is not to difficult to build in later. At the moment I am on holiday till end of october, but can look at it after that.

A URL where you see this is:

With the help of valhallas, solved. The query to get the database was not specific enough due to which it queried the database for nds-nl.wikipedia.org instead.

For an example, the link I use to see changes related to the 'Molen' category:

With the help of Krenair, pointed to alternatives via en-wiki. This is not guaranteed to keep working, but for now it works again.

@siebrand I will send a mail about this, but imho lemonbit has done the correct steps.

I think 'Overleg' is missing there?

intresting. The site fixed is www.wikilovesmonuments.org. without www it seems to just point to the default site

Per comment from Sindy, certificate is installed.

They are bots I run to harvest information from lists and linked articles from those lists, and create an overview. I used to run them on toolserver, with the migration to tool-labs I decided to run them at home again. It is probably still good to have the source in a repository.

Quick translation:

A few weeks ago, I asked Sindy Meijer from the dutch office to take this up with the company that is now doing the admin for Wikimedia NL. Appearantly this slipped, I will ask again next week.

Having the edits only suppressed on minor edits would be a solution. The bot that triggered this is also an archiving bot, who is also doing minor edits.

The first ping is to the nominator who has done the nomination, not the author of the article. It is debatable if that ping is wanted, but that should be discussed on the other ticket. I opened this ticket for the general discussion where I expected a bot-bit to disable notifications.

Problem in the specific case is that the same bot does two tasks and that it archives a notification it has done himself. On the first you might want a ping, on the second not, and rewriting a message you archive is also not nice.

Per irc-discussion the blacklist will also block the mails to the user about a message on it's talkpage, which is probably unwanted for the nomination notifications.

roughly 3 options that can be quick:

For the specific page, which is bot generated, I asked the bot-operator to just make it a proper isodate by adding a T. For a short-term fix, I think that indeed the regexp needs to be stricter.

The proposal has been announced on the village pump, and the 'overleg gewenst' (discussion wanted) page, and no objections has been raised at all, so we can assume consensus for this proposal.

I was pointed to this bug because of a feedback comment. I mostly see discussion about category editing on the page itself. Another feature hotcat offers is to navigate the category-tree, so it is quite simple to put an article in a subcat, or to bring it to a category above it. Can that feature be considered as well?

Fixed by setting the locale in the script:

On the dutch wikipedia, somebody was confused about not seeing the patrols either. I indeed think this is confusion, so I support logging the patrols separate as well.

All tools are tools that do some larger queries, but as far as I can see, only order of couple of seconds, not more. I have not gone over all queries to see if they can be more efficient, but knowing Erwin that has been looked at. So if we can (again) tune up this tool, would be appreciated, also by the users of the tools.

The webservice itself is monitored via the .bigbrotherrc, but it looks to be only looking for the proces. If the webservice is running but unresponsive it doesn't seem to be detected.

Looks to be a useful addition, I would say, go ahead to implement, but maybe make a remark next to the option about the consequences.