- User Since
- Oct 6 2014, 10:53 PM (442 w, 2 d)
- IRC Nick
- LDAP User
- MediaWiki User
- Whym [ Global Accounts ]
Mon, Mar 27
There are some problems but I think I sorted them out.
Sun, Mar 26
I am struggling to find an image containing logrotate (or its alternative). I have been using /usr/sbin/logrotate to rotate log files daily.
Jan 31 2023
Jan 6 2023
Dec 23 2022
Nov 29 2022
This might be a tangent but
Oct 27 2022
I didn't migrate it because I couldn't figure out how to use venv inside kubernetes properly. I think I now know how.
Aug 9 2022
@Esanders Thanks for the pointer. I believe the CSS solution would allow [[トーク:あ]] to be stylized as "トーク：あ" (or very similar to that). However, I would also want [[トーク：あ]] (in wikitext) to be an alias of or a redirect to [[トーク:あ]] and I don't think that's possible with CSS. Perhaps it was unclear with the description I wrote 10 years ago (!). I will try revising it later.
Aug 5 2022
@Xqt You are right, the patch works as described in this task's description. I only skimmed the code and misunderstood how it works. (I should have tested it at least before commenting, sorry.)
Aug 4 2022
Is this the same as T312773?
Aug 2 2022
@MPhamWMF If the Search team doesn't want to keep owning the task, I think we can just remove the "Discovery-Search" tag. In fact, it looks like this task was only added to "Discovery-Search" in 2021, after 10 years.
Jul 11 2022
You are right, saying the current behavior is to sort by the last post is wrong. I will change the description and the title.
Jul 2 2022
Jun 30 2022
Jun 21 2022
Apr 11 2022
(For future reference) T301649 changed the URL of the pageview service. The change of the URL had to be reflected on an allowlist used by popular ad blockers and privacy plugins: https://github.com/easylist/easylist/pull/11049
Jan 30 2022
Jan 18 2022
Jan 3 2022
Dec 3 2021
Is this different from T12268?
Aug 15 2021
Jul 30 2021
https://ticket.wikimedia.org/ redirects to https://ticket.wikimedia.org/otrs/index.pl which contains "otrs". Does this have to be changed, too?
Jul 28 2021
This seems to overlap with T124841.
Jul 26 2021
May 16 2021
Yes, let's close. It might have been slightly better if we made the bahavior configurable, but after 4+ years, I guess the benefit of doing so now is little to none. (Most people would not be using the older versions of MediaWiki any more.)
Apr 23 2021
If no, are there any reasons we could not run WHOIS commands from Clouds machines and cache them in a database?
Mar 10 2021
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.
Mar 9 2021
Just for the sake of completeness, I added some of the log items in concern into the description.
Oct 29 2020
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.
Oct 24 2020
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.
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.
Oct 19 2020
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.
Oct 13 2020
Oct 2 2020
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)
Sep 6 2020
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.
May 7 2020
Thanks, it looks good to me. :)
May 5 2020
May 3 2020
Apr 29 2020
Resolved by https://github.com/whym/whois-gateway/pull/15, thanks to @QEDK.
Mar 4 2020
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.
Aug 25 2019
Jul 22 2019
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.)
Jul 2 2019
May 7 2019
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.)
May 6 2019
Apr 19 2019
Apr 14 2019
Sorry, the link in the description was not adequate - it was done before I updated Pywikibot. I replaced it with newer examples.
Apr 13 2019
@Dvorapa in which commit was it fixed?
Apr 12 2019
Mar 26 2019
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.
Dec 19 2018
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'.
May 28 2018
I think so, unless there are still plans/needs for supporting minute and month.
May 1 2018
Apr 10 2018
@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.)
Apr 8 2018
I added some details into the description which might help people implement this idea.
Mar 3 2018
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.
Mar 2 2018
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.
Feb 14 2018
Dec 21 2017
Dec 9 2017
The problem seems to be caused by this match (in load_page() of archivebot.py) which is not aware of nowiki or comments: