Difference between revisions of "User talk:Kynikos"
Latest revision as of 10:34, 24 November 2019 Integrating Google searches into ArchWiki
- 5 Media
- 24
How to use Wiki Monkey to sort users
- 25
Deletion of outdated Russian articles
- 26
Preparations for block device encryption)
MediaWiki and help pages centralization
MediaWiki tries to centralize help pages, many links in the interface now lead to (using
Special:MyLanguage from Extension:Translate to detect the language; btw see also [3]). As we do many things differently, I think that we should keep linking to our pages by overriding the new defaults in MediaWiki: namespace.
For example, the "Editing help" link in edit pages now links to mediawiki.org (MediaWiki:Edithelppage).
-- Lahwaacz (talk) 22:21, 5 July 2014 (UTC)
- Thanks for the heads up, I'm not sure yet what to do here, because we do many things differently indeed style-wise, but relying more on the upstream docs for syntax guidelines and generic instructions on how a wiki works could be taken into consideration. I'll have a deeper look into that, and maybe start a discussion somewhere. -- Kynikos (talk) 05:00, 6 July 2014 (UTC)
External links
There is something wrong with Special:LinkSearch:
- The two links from ArchWiki:Contributing#Use internal links (http links and https links) don't show anything. When they are changed to match on all namespaces, the first shows something, but for the second there is only one positive!
- This query is cluttered with links to AUR packages, most of which go over templates and still there is only one link to the wiki.
There are many links to wiki that should be matched: links to diffs or history, Template:Out of date etc. use full url to talk pages, and there are even links to articles [4] (I bet there are some even in the main namespace). It seems that MediaWiki treats all external links starting with or as internal, which is very unfortunate.
-- Lahwaacz (talk) 07:26, 6 July 2014 (UTC)
- I'd even say that every link is ignored: it could be that, in order to indicize the external links, MediaWiki must first process the wiki markup (internal links, interwiki links, transclusions...), so then it has to ignore the urls that point to the wiki itself, otherwise they would be too many (?!?). The only problem is User talk:Karlswab, I can't really explain why its https link is shown... I've tried to reproduce it on User talk:Kynikos.bot but to no avail, really weird. -- Kynikos (talk) 05:52, 7 July 2014 (UTC)
- Found it! See [5] and the linked commit. We could submit a feature request to set $wgRegisterInternalExternals to true, but it has been disabled for a reason (at least on bit Wikimedia projects, the 50GB value is too much for Arch wiki). -- Lahwaacz (talk) 08:20, 7 July 2014 (UTC)
- Uh good job! However it's not clear whether setting $wgRegisterInternalExternals to true would only record the internal links formatted as external, or all the internal links regardless of their wikitext form. In the latter case, turning it on would be useless as it wouldn't help fixing the wrong-formatted ones.
- Then there's still User talk:Karlswab: $wgRegisterInternalExternals was apparently introduced in 1.16.0, which we installed in 2010, however the link in that talk page was added in 2012, so in theory it should have not been recorded...
- What we can do:
- Ask about the exact functionality of $wgRegisterInternalExternals
- Update/remove ArchWiki:Contributing#Use internal links
- -- Kynikos (talk) 12:59, 7 July 2014 (UTC)
- I'd say that this would definitely affect only the external links (syntax sense). From the quick look at the code, the
addExternalLinkmethod is called only from parts of the parser responsible for formatting the external links; then there is
addLinkfor the internal (and interwiki) links. See also [6] which talks specifically about Special:LinkSearch.
- About User talk:Karlswab, it is possible that for Arch wiki the $wgRegisterInternalExternals variable was first set to true and later set to default. We could try to find some older links not being registered to confirm this paradox :P
- -- Lahwaacz (talk) 14:02, 7 July 2014 (UTC)
- Yeah, you're right, and these two observations put together would also explain why a link to a search like those has been in my public task list for ages, also allowing me in 2012 to do this series of edits with my bot, which was clearly launched on Special:LinkSearch, actually also fixing some wiki.archlinux.org links (some of which I had to revert then, teaching me that links cannot be converted automatically).
- I've removed the section in ArchWiki:Contributing for the moment. We could also open the report for $wgRegisterInternalExternals, but I'm not sure how lucky it could be, considering the age of the other open wiki bugs; maybe this one can wait for the resolution of The Bug, which at a certain point we'll probably have to bump somehow, being a very quick fix in practice. This discussion will also remind to re-add the section in ArchWiki:Contributing then.
- PS: I'd also be curious to re-save User talk:Karlswab and see if the link in the search really disappears :P
- -- Kynikos (talk) 14:44, 8 July 2014 (UTC)
- I have tested this on LocalArchWiki, and the externallinks table (with 1565 links to wiki.archlinux.org domain) takes 36.2MiB. Since wiki.archlinux.org is not a local domain for LocalArchWiki, I did not even have to set $wgRegisterInternalExternals to true, which also means that I can't determine the increase in space, but for ArchWiki it is surely in order of MiB, not GiB.
- Edit: After the $wgRegisterInternalExternals is set to true, it will be necessary to run the RefreshLinks.php maintenance script to update the database; this should be noted in the bug report/feature request.
- -- Lahwaacz (talk) 14:23, 22 December 2014 (UTC)
Redirections are visible in search
Hi Kynikos.
I noticed all pages which are redirections to others are visible in search results. For example, search for Android, and you will get Android-sdk and Android as results where Android-sdk points to the main Android article. The same with the VirtualBox article I'm currently maintaining. Virtualbox --> VirtualBox, Installing Arch Linux in VirtualBox --> VirtualBox, VirtualBox Extras --> VirtualBox,... I think such redirections shouldn't appear in search results, like it is on Wikimedia/Wikipedia.
Also, I wonder if the translation titles are really needed in search results too e.g. VirtualBox (简体中文). Why not provide only English versions as result, then if the user wants the translated (and outdated) content, he can click on the links on the left. -- wget (talk) 19:34, 2 August 2014 (UTC)
- There doesn't seem to be an option in the user preferences, and I don't think it's possible to uncheck it globally, see mw:Manual:Configuration settings#Search (and anyway that would require FS#35545 to be fixed). However I'd be against unchecking it by default because if somebody searches for "android sdk" he has to get the redirect as a result, and this is one of the main reasons why we create redirects in the first place.
- About results in other languages, MediaWiki is completely unaware of our language tagging system, which is regulated by Help:i18n, but it's worth mentioning that implementing Help talk:i18n#Language namespace(s) in place of suffixes? would solve the problem.
- -- Kynikos (talk) 04:06, 3 August 2014 (UTC)
Smart cards
Hi Kynikos. Just after some updates on the VirtualBox Arch Linux article, I'll write a complete documentation for the Belgian eID (identity card) requiring me to link to the official website and some posts from blogs belonging to Arch Linux enthusiasts. I'm also gonna upstream to Wikipedia some information I discovered in very hidden PDFs on the website (hardware specifications, etc. which are not really related to Arch Linux). I don't know how I'll proceed yet: maybe write a complete Arch Linux article then upstreaming or the reverse order. I don't know. -- wget (talk) 01:07, 10 December 2014 (UTC)
- Sounds great, however I can't help you plan this :) There is however Estonian ID-card already, maybe it can inspire you. -- Kynikos (talk) 05:49, 10 December 2014 (UTC)
- Thanks for the hint. I see we have the Common Access Card article too. In order to avoid duplication, since both CAD, the Estonia and Belgian eID are all smart cards, I'm gonna merge these articles together and make a meta article called Smart card (no need to create a Java Card article, the vast majority are Java cards any way). -- wget (talk) 12:00, 11 December 2014 (UTC)
Arch Development category is dead
Hi Kynikos.
Reading my mailing list messages, I was wondering how official repositories signoffs were actually performed. I decided to browse the wiki to answer my question and realized the [7] category was completely outdated, not being able to find a clear answer. I would like to move all articles from that category to the DeveloperWiki: where already a bunch of updated information are available. I really meant MOVING not creating a redirection: my aim is to clean this wiki as much as I can. And creating redirection is counterproductive: this doesn't clean category list and table of content.
I already made that suggestion to you #Redirections are visible in search.
Also, with information I get from IRC today, I'ld like to provide a big DeveloperWiki:Website page where we will put all information I gleaned about our the ArchLinux website structure is working. I meant gleaned because I'm subscribed to all ArchLinux mailing list and am reading them daily.-- wget (talk) 14:11, 8 January 2015 (UTC)
- As its name says, the so-called "DeveloperWiki" should be maintained by Developers, but they don't, so of course those articles have become obsolete. Right today I've marked some more for deletion. I haven't understood where you'd move those articles though. Redirects shouldn't be categorized, so they shouldn't appear in Category pages, nor increase the count numbers in Table of contents.
- You've already found DeveloperWiki:Archweb, you can
move it to DeveloperWiki:Website andexpand it if you want, I don't have any objections :) (actually, scrap renaming the article, "Archweb" does seem to be the official name of the project[8])
- -- Kynikos (talk) 15:28, 9 January 2015 (UTC) (Edit: 06:51, 14 January 2015 (UTC))
Highlighting whitespace in diffs
If I remember correctly, MediaWiki used to highlight whitespace in the diffs, e.g. when a space was added/removed it used to be highlighted with blue background. This is no longer the case and sometimes it is rather annoying, see e.g. [9]. Have you also noticed the change or is it just my imagination? -- Lahwaacz (talk) 09:21, 6 February 2015 (UTC)
- Look at this diff [10], you'll see a whitespace here.
- Regretfully, whitespace/tab changes aren't highlighted
when they're placed at the end of a linesometimes (ughh, I can't realize now when it is happening) neither with old 1.22 engine nor with 1.24 :( — blackx (talk|contribs) 10:19, 6 February 2015 (UTC)
- I don't remember if whitespace changes were always highlighted before the recent software upgrades; however the fact that I never noticed this behavior either might indicate that it's indeed a new bug?
- In any case it's clearly a bug in the diff engine, so it should be reported upstream, hopefully one day it will be fixed... (but don't sit there and wait in the meanwhile eh ;) )
- One reason this bug may happen could be linked to the fact that the diff engine outputs differences with <ins> and <del> tags, and this may clash with some whitespace-related XML/HTML behavior.
- — Kynikos (talk) 07:36, 7 February 2015 (UTC)
- Considering that adding a single space is the recommended way to make a dummy edit, there might indeed be a connection with rendering and the result is probably very buggy. At least changes that make difference in rendering seem to be highlighted consistently, e.g. [11].
- I'll see what can be found upstream, until then wikEdDiff seems to be a viable alternative (but has to be run with Greasemonkey).
- -- Lahwaacz (talk) 12:43, 7 February 2015 (UTC)
Minor bot edits
Hi, I've noticed that I'm not getting any email notification for bot edits marked as minor, e.g. [12]. It does not seem to be a bug, it's more likely a feature. To exploit it, maybe all bot edits with an edit summary like "automatic update" should be marked as minor. What do you think? -- Lahwaacz (talk) 20:51, 1 March 2015 (UTC)
- Since I patrol the recent changes, I don't use notifications: is that behavior independent of Email me also for minor edits of pages and files in Special:Preferences#mw-prefsection-personal and Hide bot edits from the watchlist in Special:Preferences#mw-prefsection-watchlist?
- Anyway, currently I think all the "automatic updates" that I do regularly are:
- Table of Contents: normal user, normal edit (I'm going to change it to minor).
- ArchWiki:Statistics: bot user, normal edit (not marked as bot, I'm going to change it to minor though)
- Sorting ArchWiki:Administrators and ArchWiki:Maintainers: bot user, bot/minor edit.
- In general, I think marking edits done with a bot account as "bot" and/or "minor" should be decided case by case, primarily considering the effects on Special:RecentChanges, and only then on notifications. You may want to also consider solving the problem on your end by setting custom filters in your email client.
- This said, I'm open for discussing each of these cases separately, or any others I might have omitted, of course.
- — Kynikos (talk) 03:59, 2 March 2015 (UTC)
- Yes, I have Email me also for minor edits of pages and files checked and Hide bot edits from the watchlist unchecked. Btw, I didn't find an option for Show bot edits in RecentChanges by default, I think there is none.
- As for the email client, I already have filters to mark notifications of my bot account as read and check the edits from the list of contributions, which includes also pages not present in my watchlist. This way I can avoid checking an edit twice. I could add another bot account to the filter, but I think it's better to mark the edits as minor instead, because this will apply to all users and not just me :)
- Edit: I've modified statistics.py to make properly marked bot edits. Since the past edits were already being performed by a bot account, I assume it was a bug -- or would you like to complicate things and let bots do regular non-bot edits?
- -- Lahwaacz (talk) 18:15, 2 March 2015 (UTC)
- Eheh honestly I originally didn't put the "bot" parameter in that query on purpose, thinking there was no reason not to show the edit in the RecentChanges (I reason in a "show-all-except" way instead of "hide-all-except", and I don't mind seeing bot accounts acting as normal users), but I don't feel strongly about it at all, and I'll take your concerns about notifications as a valid argument in favor of hiding it, so I've pulled the new version and will use it from now on :)
- Are you ok with me updating Table of contents as a normal user?
- — Kynikos (talk) 14:08, 3 March 2015 (UTC)
- Well, bot edits are included in the RecentChanges, only hidden by default. Unfortunately there is no way to configure MediaWiki to show them by default, neither per-user nor globally. I think that the decision whether to mark edits as bot or not should be driven by the way they were performed (manual or automatic), not by the intention to hide or show them in some list by default, which should be only the incidence (and ideally configurable). Of course all this decision making would be much simpler if regular users could mark some edits as bot, if only via API, and ideally supply a tag indicating the software that made the edit. Then we would not need the dual accounts at all...
- As for Table of contents, it is not updated daily, so my argument with notifications does not stand. I'll leave this up to you.
- -- Lahwaacz (talk) 20:48, 3 March 2015 (UTC)
- Interesting discussion, I've never really thought in depth about whether there's a general rule that makes me decide when to use a bot account (and possibly the "bot" tag) or not to perform some edits. I think I've always seen bot accounts as a means of not polluting the (default) recent changes with numerous, similar, minor, automatically-saved changes that theoretically nobody should care too much about (except for the bot operator who is supposed to check them, at least by sample) (yes, there's also the advantage of having higher query rates allowed from the server). There are exceptions though, like the sorting of admins/maintainers pages, which I see as only a technicality of no consequence that can easily stay behind the scenes; also, I tend to use the bot account when testing something technical, like the behavior of templates etc.
- I'm wondering what you exactly mean with "the way [edits] were performed (manual or automatic)": is "automatic" as in "the text has been modified with other means than pressing character keys on a keyboard", or as in "the changed text has been saved with other means than pressing the Save page button in an editor's page"? In the former case I'd disagree it could be a sufficient test to distinguish between bot and non-bot edits, think for example of editor assistants like Wiki Monkey or external editors like vim; in the latter case, quick edits that I do with Wiki Monkey e.g. when fixing a few double redirects, updating ToC articles, or fixing the backlinks of an article would require me to switch to the bot account, even though I'd see such edits as more human-like than bot-like.
- — Kynikos (talk) 07:15, 4 March 2015 (UTC)
- Well, semi-automatic is, by definition, between automatic and manual. Obviously the bot/non-bot distinction is too strict, unfortunately MediaWiki does not provide anything better. There is an attempt to implement revision tagging (see mw:Manual:Tags), but it does not behave as I'd suspect. We have Special:Tags on ArchWiki, but the
managechangetagsright mentioned in the manual as "given to administrators by default" is not listed in Special:ListGroupRights nor mw:Manual:User rights. Hence I think that these tags are usable only from extensions, perhaps a special extension is necessary to edit the tags.
- Anyway, I haven't done many semi-automatic edits in a while, but I'm inclined to mark them as normal/non-bot (i.e. not mark them at all) and reserve the "bot" mark only for automatic edits. After all, we don't require other users to make a bot account to do semi-automatic edits.
- -- Lahwaacz (talk) 14:24, 7 March 2015 (UTC)
- So, can I infer that your definition of "manual" vs "automatic" is based on the saving method, i.e. click on Save page vs API query (see the second paragraph of my previous post)? In this case Wiki Monkey's bot and special plugins (e.g. updating ToCs or double redirects) are "illegal" when run with a normal account, if we want to apply this rule strictly. What we call "semi-automatic" edits are in fact "manual" ones, under this definition, it makes it pretty obvious to me :) If we really need a definition, I think that is the only clear one we can give.
- However I was thinking: why is it that we need a separate account for bot edits after all? I think that for MediaWiki that's only a difference in rights, but when it comes to distinguishing the single edits, MediaWiki only looks if the query has the bot parameter set, which can be set only by accounts in the bots group. In practice, this means that I could simply add our "normal" accounts to the bots group too, and nothing would change when we do normal, manual edits, but we would be able to control when the bot parameter is added by just properly setting it in the script queries that need it, without the need to switch account too (I hope I've made it clear enough).
- — Kynikos (talk) 03:47, 8 March 2015 (UTC)
- Yes, I think that the following definition is natural: if the text is both modified and saved manually, it is manual; if it is modified automatically and saved manually then it is semi-automatic; and if it is both modified and saved automatically, then it is automatic.
- If I remember correctly, the edits of bot accounts which were saved via clicking on "Save page" in the web UI are automatically tagged as bot edits. Or is there a way to change this absurd default?
- -- Lahwaacz (talk) 07:59, 8 March 2015 (UTC)
- Well, the definition is ok, but applying it strictly would make maintenance harder in some instances, for example a few hours ago I fixed a bunch of double redirects with Wiki Monkey's plugin, which qualifies them as automatic edits: if I had to switch to the bot account it would have taken too long and alomost defeated the purpose of having a quick button for that. That's why in practice I think I'll keep just deciding case by case.
- About manual edits with bot accounts you're right, I completely forgot that, so the idea is discarded of course, as I don't know of a way to change that behavior either.
- I'll keep this discussion around for a while, just to see if after re-reading it in the future I'll be able to come up with a better conclusion.
- — Kynikos (talk) 10:05, 9 March 2015 (UTC)
- Update: Since 1.25.X users and bots are supposed to be able to apply certain tags by themselves, see mw:Help:Tags. The page is unfortunately still empty; the API edit module takes a new tags parameter (unfortunately not described in mw:API:Edit yet), but it is not clear if it will be possible to set tags also from the web interface. I will try this sometimes... -- Lahwaacz (talk) 21:39, 1 September 2015 (UTC)
Wiki Registration AntiSpam box "FunnyAnswer" Bash Note required
Just registered and already contacting an admin (u_u), in any case, While registering after I was amused by the AntiSpam "FunnyAnswer" box, I copied the text to my terminal, and pasted the code. It was apparently wrong! , did it 3 more times, all the same result.... Then, for no good reason, I decided to try Bash, as I normally use "fish", and surprisingly enough it gave another result, which was easily accepted. Apparently fish got "date -u +%V`uname`" translated into "14`uname`", instead of "14Linux".
I understand that most users wouldn't replace Bash, but I think it is worth a mention to use it for the challenge. Additionally, while we are at it, maybe add a newbie friendly
"What is the output of the following line in the Bash terminal" [code][/code]
With a possible link to the Bash wiki page, for a toddler user, who just decided for some reason to edit the marvellous ArchWiki, instead of the soulless
"What is the output of "date -u +%V`uname`|sha256sum|sed 's/\W//g'"?"
>>> Challenge form field is; <input type="text" class="mw-ui-input" name="FunnyAnswer" tabindex="9" value="" id="FunnyAnswer">
—This unsigned comment is by Serag4000 (talk) 4 April 2015. Please sign your posts with ~~~~!
- Thank you for the feedback and welcome to the ArchWiki!
- Yes, backticks don't work in fish [14] [15] [16] :)
- It happens frequently that new users report registration difficulties in the forums, although I'm not sure if somebody's ever proposed to explicitly mention Bash in the question, actually I don't think it would be a bad idea. In any case though, patching the captcha is beyond the powers of a wiki admin, and a request in the bug tracker should be opened for that, so you may want to go that way on your own, or I'll just put this in my TodoList™ and discuss it at some point in time.
- — Kynikos (talk) 03:08, 5 April 2015 (UTC)
File uploads?
Forgive me for asking this dumb question, but are file uploads enabled on this Wiki? According to this there should be an "Upload File" link under "tools", but I don't see it. Some files have obviously been uploaded, but the most recent was in 2008, and I'm wondering if file uploads were disabled since then. I would like to upload some diagrams now and then, but I can't figure out how. Am I just looking in the wrong place? EscapedNull (talk) 15:43, 18 April 2015 (UTC)
- It's not a "dumb question", don't be afraid of asking anything you want :) File uploads are deliberately disabled on this wiki for regular users, the reasoning being in Help:Style#Non-pertinent content. Disk encryption has some examples of beautiful Unicode diagrams by User:Sas, who explained how he made them in Talk:Disk encryption#Unicode graphs.2Fpatterns: do you think that's a viable solution for you? — Kynikos (talk) 03:56, 19 April 2015 (UTC)
- Thanks for the reply. I've used ASCII Flow before and its functionality is pretty limited, and I don't use Kate, but it did give me the idea to search for Vim plugins, where I found this one right off the bat. I'll give it a try soon and see about using it instead. I asked about file uploads because I like the dot language, which only supports exporting SVG and simple image formats. Maybe someday Arch Wiki will support Extension:GraphViz? EscapedNull (talk) 11:03, 20 April 2015 (UTC)
- Nice, if you make it to draw those diagrams with the boxdraw plugin they will also be more examples we will be able to show to users who will come with the same question! About the GraphViz extension, never say never, but I don't see it as something happening in the foreseeable future :) — Kynikos (talk) 13:56, 21 April 2015 (UTC)
Concept of non-English TOC
Hello, Kynikos! At this discussion I offered to placing two table of contents side by side in non English Tables of categories, but nobody answered. It is important, because there are for example some articles only in English, but Russian people may be still interested in them (for example, pages about Laptops). Also, doing so will solve problem of out-of-sync numbering in English and non-English table of content.
Sorry for contacting you directly, but maybe you can help me with that? I think we need to create/edit your script, that do automatic updates. I have made a concept of ToC for non-English pages. Is something like that possible? — Agent0 (talk|contribs) 17:03, 5 September 2015 (UTC)
- I might be able to look at this after my BS exams in a few days. In the meantime, if keeping the corresponding numbers on the same line isn't important, you could take a look at User:Lahwaacz/ToC test for a simple solution: on the real Table of contents (Русский) you need to transclude only the English version. If the content is wrapped into the divs properly, Wiki Monkey should preserve the layout and only update the left column. -- Lahwaacz (talk) 17:23, 5 September 2015 (UTC)
- Hey Agent0, I'm aware of the discussion you reference, but unfortunately at the moment I don't have the time to follow complex discussions, so that's why I'm delaying answering :) Of course something like that would be possible, but I can't work on it now, sorry...
- And thank you Lahwaacz for trying to help, if you want to implement the idea go ahead of course, this is probably something more suited for wiki-scripts after all :) Good luck from me too!
- — Kynikos (talk) 12:07, 6 September 2015 (UTC)
-)
How to use Wiki Monkey to sort users
Hi, Kynikos! Could you please explain how to use the awesome Wiki Monkey (Standalone version) to sort users in the list by their recent edits number (e.g. for ArchWiki Translation Team (Русский)#Команда)? Actually the ArchWikiSortContacts plugin is disabled, I couldn't find anything useful on GitHub, and I guess the discussion you had earlier is no longer up-to-date (as there are no such sections, configs and comments for the script). -- SlavMetal (talk) 19:04, 15 September 2019 (UTC)
- Hey SlavMetal, of course I can help, Wiki Monkey has changed quite a bit since that 2015 discussion, so I've taken this opportunity to write some documentation for the plugin, see [22], I've also tested it in [23] as an example, let me know if it works for you :) -- Kynikos (talk) 17:09, 16 September 2019 (UTC)
Deletion of outdated Russian articles
Hi, Kynikos! I have noticed recently a few Russian articles that I think would be a good idea to delete:
- Sugar (Русский) — outdated and untranslated content
- Ceph (Русский) — same as above
- Timezone (Русский) — totally outdated content with almost no information (see English article for comparison)
- Mouse buttons (Русский) — same as above
- TigerVNC (Русский) — same as above
- MIDI (Русский) — intro is in Russian, but everything below is outdated and untranslated
- Bluetooth headset (Русский) — same as above
- Browser plugins (Русский) — a few sentences in Russian about the Adobe Flash Player, but all other content is outdated and untranslated
In all cases above, user is presented with totally outdated content that is not even in Russian language (or with a couple of sentences only), which confuses him and also doesn't give any base at all to make or update a translation, so user will have to
Ctrl+C and
Ctrl+V the whole content from original article anyway.
Yeah, I can just copy-paste the current English content, but I don't see any point as there are no people willing to translate/maintain these articles anyway. So if you agree to delete those articles, I'll remove links to them beforehand.
SlavMetal (talk) 21:50, 7 October 2019 (UTC)
- Hi SlavMetal, I'm quite a religious follower of Help:Procedures#Remove an entire page, and since those pages have a multi-revision history I suggest you simply redirect them to their respective English articles, so that's also one more thing that translators can handle autonomously ;) (no need to flag them with Template:Redirect) It also makes sense to not break URLs that have been published for a while, and their English articles seem the best backup targets for them. -- Kynikos (talk) 10:40, 8 October 2019 (UTC)
Preparations for block device encryption
Sorry I thought this part was quite circumvoluted, the repetition of "you", exclamation, block starting with upper case... but I may have misunderstood something, let me know if I can still help or if it is fine like this. If this is about the dead link, my mistake it was a typo I was going to immediately correct. --- Kewl (talk)
- Hi Kewl, it's taken me a little while to guess what you're referring to here, then this idea came to my mind: is it possible that you're talking about these edits that you then rolled back yourself, very likely accidentally, thinking that I did it because the summary says "to last revision by Kynikos"? If so, those edits were perfectly fine to me :) -- Kynikos (talk) 05:05, 24 November 2019 (UTC)
- No problem at all of course, in fact misclicking rollback links was a problem big enough to encourage me to make a feature on Wiki Monkey, enabled by default, that hides rollback links in Special:RecentChanges and Special:Contributions pages (but it still deliberately leaves them available in diff pages, I don't know if the link that you followed was in a diff page, in that case not even Wiki Monkey would have saved you :P ). (PS. If you just want to hide them all, I guess even a simple user CSS rule can do it) -- Kynikos (talk) 10:19, 24 November 2019 (UTC)