There might be a common cause, but I think the old task was about edits. My problem here is about bot actions, not bot edits.

In T276613#6887916, @MisterSynergy wrote:

Just for the sake of completeness, I added some of the log items in concern into the description.

whois.toolforge.org is now using ST47's patch. (Thanks again.) @ST47, are you going to send a pull request and get it merged to the upstream repository? That would be better for long-term maintainability.

Ah, that's right. Then there is no reason to withhold it, at least as a short term fix. I'll think about things like highlighting missing information later. Thank you for your help.

In T265784#6565219, @ST47 wrote:

I tried using ST47's version of ipwhois on a test instance, while not changing the original tool yet. However, it looks like currently the block is lifted? I see no difference in the results - both work.

Is the problem larger than the current title and description of this task suggest? The title of this task only mentions mailing list descriptions. Yet the two comments on Oct 18 say that we have a problem in body text of individual emails, at least more recently, too.

• I'm wondering if the whois tool at toolforge should have some mechanism of throttling, if it was the culprit.
• Was there a large amount of automated access to RIPE via the the whois tool? I cannot verify because as a tool maintainer I don't seem to be able to see recent access logs.

In the case of Japanese, the encoding set by the server was euc-jp, not ascii. When I manually override the encoding in the browser side, it is fixed until I reload. (Tested on Mozilla Firefox 81.0)

@Tacsipacsi
The description says "to all Wikipedia talk pages and potentially, other projects." :) I suppose Wikipedia must be supported for this task to be resolved while others might be optionally supported along the way.

Thanks, it looks good to me. :)

In T251693#6109510, @alexhollender wrote:

As far as I can tell they are quite similar. I think the appropriate process here might be to start a discussion on the Talk page of the logo itself? https://commons.wikimedia.org/wiki/File:Wikipedia-logo-v2-ja.svg

Resolved by https://github.com/whym/whois-gateway/pull/15, thanks to @QEDK.

Was there anything you can share from your private correspondence? I don't always ask this, but the public discussion here and on-wiki seem to be pending on what you might have been discussing privately.

Note to @Jeff_G: you might still see the bug on Commons, but that's expected. It might take some time before I update ArchiverBot@Commons to reflect the bug fix. (Maybe next weekend.)

Which URL should I use instead? There is https://afrinic.net/whois/ but I'm not sure I can directly link to a search result there. (It's a dynamic tool.)

Sorry, the link in the description was not adequate - it was done before I updated Pywikibot. I replaced it with newer examples.

@Dvorapa in which commit was it fixed?

For the record, the problem seems to have been resolved before I do anything. Ideally I'd like to know the reason in order to prevent similar issues in future, but I'm not really sure.

If the two time scales are still needed, I would suggest using longer forms ('600min' and '2mon'') or full spells ('600minute' and '2month', not sure if it should be plural or we should support both). The only problem for me was that it was confusing to have to distinguish minutes and months using lowercase 'm' and uppercase 'M'.

I think so, unless there are still plans/needs for supporting minute and month.

@Tacsipacsi Do you think T191901 addresses that? Allowing to set a wiki-wide default setting sounds like a good idea, but a separate one.

Description edited - hopefully this is now more discoverable by keywords like 'Mobile.css'.

Thanks - the workaround suggested there seems to work for me for the moment.

Is there anything that local wikis have to do after the change? Japanese Wiktionary (still) has CSS rules for self links in https://ja.wiktionary.org/wiki/MediaWiki:Mobile.css but it doesn't seem to be applied to https://ja.m.wiktionary.org/wiki/%E3%81%AA%E3%81%8D%E3%82%80%E3%81%97 like they used to be. The intended targets on that page include the first appearance of 泣き虫 which is not bolded any more. (underlines appear when I hover the pointer over them, though.)

In T72249#4114632, @binbot wrote:

• some delay may be neccessary and should be implemented (we don't want people to mark sections as done at 2:00 am and the bot to archive them at 3:00 am before anybody could have seen the changes). I think it So "algo = old(30d) OR marked(done|2d) would be better (where | is not neccessarily the best choice for separator character)

I added some details into the description which might help people implement this idea.

Do we have a clear path forward, however? It looks like we have consensus on that self-links should be styled as proposed (bold, inherited color, etc). But there is a disagreement over how to implement the desired style: 1) using <a> and add CSS rules, or 2) using <strong>. And it looks like from performance perspectives <strong> is preferable, while semantically <a> should make more sense.

I'd like to present a usecase outside of navboxes: at Japanese Wiktionary, we add quotes from literatures to provide examples of the use of a word, as many Wiktionaries do. The appearances of the headword in an example sentence is highlighted by bolding it.

The problem seems to be caused by this match (in load_page() of archivebot.py) which is not aware of nowiki or comments:

Re: GCI: it appears that GCI expects a participant to solve many small and beginner friendly tasks during the period, not one large project:

In T119791#2018340, @murfel wrote:

I'll take that into account if I manage to get to this. (Anyone else should feel free to overtake this task.)

Not sure if we want to remove the timezone requirement from parsing. We want to discriminate timestamps from other mentions of date and time. An explicitly written timezone symbol is an indication that it's probably not a part of a normal sentence.

Thanks for notifying me. It was a (probably incomplete) copy of dumps.wikimedia.org/other. The largest subdirectory was /other/diffdb/ which I have deleted. I was particularly interested in https://dumps.wikimedia.org/other/slow-parse/ - I hope the remaining 600MB is okay to stay.

To be fair, the "wrongly" segmented tokens might matter less because most of them looks less likely to be used (at least as a stand alone search keyword). I wouldn't normally search for "こうじる" (an uncommon spelling of "講じる") unless perhaps I'm looking for misspellings to correct.

Thanks for providing additional samples! Here are some quick observations I had. Hopefully some of them are relevant.

I'm happy to help with speaker review. I take that I would be supposed to check if the frequencies of the different forms seem right or not. (e.g. if some unlikely forms appears more frequent than others.) Is this correct?

@leila Is the translation of https://ja.wikipedia.org/wiki/MediaWiki:Reader-segmentation-3-privacy still needed?

@MtDu Just added some code examples into the description.

I found two with a google search.

Is there a tag for issues of on-wiki scripts?

In T122755#3220618, @TheDJ wrote:

Thanks for the ping. To be honest, I don't remember precisely what tables I had there (it was a long time ago), but I believe mines are safe to delete at this point.

Just noting that, instead of Phabricator tasks, specific bugs and enhancement ideas of the app have their own "issues" on GitHub https://github.com/commons-app/apps-android-commons/issues. If anyone is looking for ideas not mentioned above, I recommend checking these out.

Just noting that, instead of Phabricator tasks, specific bugs and enhancement ideas of the app have their own "issues" on the said GitHub project: https://github.com/commons-app/apps-android-commons/issues. If anyone is looking for ideas not mentioned above, I recommend checking these out.

Commons App for Android also needs to implement this: https://github.com/commons-app/apps-android-commons/issues/328

From https://gerrit.wikimedia.org/r/#/c/314847/: