User talk:Kynikos

From ArchWiki
Jump to: navigation, search

Feel free to leave here your comments on my edits or anything else you want to talk about: I'll reply as soon as I can!

Xyne-related page edits after Powerpill, Bauerbill... discontinuation

See Xyne-related page edits after Powerpill, Bauerbill... discontinuation.

Where should translations go?

Hi! I'm wondering where the Archwiki team wants new translations to go? On the page ArchWiki Translation Team I get the feeling that translations should be placed under At the same time there are national wikis as well, at different stages of development. In my case this is, which only contains a few articles, and is generally lacking links to the main Wiki from what I can see. What is the policy on where to put translations?

Hi and welcome! I'm glad to know that the Swedish website has come back to life :) Since MediaWiki is _not_ designed to handle internationalization (it requires resorting to workarounds like the suffix one we're using here) the ideal goal would be to move each language to its own separate wiki, for ease of maintenance. So, in your case, all Swedish articles should now be moved to and replaced with interwiki links on at least the English page, e.g. [[sv:Huvudsida]]. -- Kynikos (talk) 15:23, 4 May 2012 (UTC)
Ah, I forgot to mention that if you want to add an interlanguage link to a protected English page, you can just ask on its talk page, and it will be added by one of us admins as soon as possible! -- Kynikos (talk) 15:28, 4 May 2012 (UTC)

On a secondary note - poorly developed regional wikis might work as a black hole for new users (turned off from arch due to lack of documentation) if they do not link to the main wiki for untranslated topics. Ideally they should cover the entire topic tree, and link to the anglish main wiki for untranslated articles. Granted, most potential new users that find a poor regional wiki probably continue searching and eventually find, but not necessarily all of them.

That's why we must exploit as much as we can the native tool that MediaWiki offers for keeping the various local wikis linked with each other: interlanguage links (example above).
Until the Swedish wiki lacks important articles, at least its Main Page if not also other important articles should instruct Swedish users to search for missing content on the English wiki.
-- Kynikos (talk) 15:23, 4 May 2012 (UTC)

Text shift in discussion answers

I noticed that the discussion pages of the wiki, in order to indicate that the piece of text written actually answers a comment from a guy above, we are using colon to shift our answer. The problem appears on long discussions page (like the beginner guide, I'm coming from), when we answer to answers answering answers...

I think it would be better to use a @name statement: this indicates we are answering directly to the guy whose name is written. And this avoid left space waste (especially on mobile phones, I couldn't even read the whole thread on mine yesterday, because of the so long shift). -- Wget (talk) 13:10, 5 August 2013 (UTC)

Well, about indentation we're just following Wikipedia's standards: Wikipedia:Help:Using_talk_pages#Indentation, Wikipedia:Wikipedia:Indentation.
About long discussions, outdenting can be used, Wikipedia:Wikipedia:Indentation#Outdenting.
I admit that the @ method wouldn't be such a silly idea, it would work with short discussions, but it wouldn't allow branching out long discussions. On wide screens the "left space waste" is negligible, and on my phones (Android) the browser correctly manages to fit long discussions to the screen width, I don't understand why your phone can't do that ^^
-- Kynikos (talk) 13:41, 6 August 2013 (UTC)

Integrating Google searches into ArchWiki

Re-reading the discussion on my talk page (User_talk:Jstjohn#Unused_redirects) made me think that we should try improving the search functionality of the ArchWiki. Native MediaWiki search is really awful in my experience, and I'm guessing many others feel the same way.

The easiest way to improve it would be to integrate Google search directly into ArchWiki. A brief search on Google led me to [1] and [2], which are two ways to integrate Google search into MediaWiki. Even if those two aren't ideal solutions—I haven't looked at them in-depth—there are likely to be several other ways of integrating Google search into MediaWiki. So consider this a very nascent proposal for extending/improving search quality on ArchWiki without necessarily proposing a certain implementation.

I don't think that we should completely replace native MediaWiki search (yet?); however, integrated Google search would be a very useful alternative search feature that everyone can use.

-- Jstjohn (talk) 00:15, 5 December 2013 (UTC)

I don't have a particular preference for one search engine or the other, however extensions can only be installed by the Devs, who have access to the repo, so a bug report should be opened for these things. In particular User:Pierre is the one who takes care of the wiki, and *IIRC* he tends to be against installing new extensions. -- Kynikos (talk) 09:18, 5 December 2013 (UTC)

Crazy idea about interlanguage links

If ParserFunctions extension was installed on ArchWiki, it would be possible to implement an (almost) fully automatic solution to the problem of interlanguage links, similar to [3], [4]. I think it would be possible to adjust it to the layout currently used on ArchWiki, so no mass renaming would be required.

Intended layout is that we would have single central template to be used on all pages, similar to Template:i18n, that would include the [[subtag:Page Name]] links for all languages. There would also be checking if the localized page exists (using the #ifexist function from ParserFunctions) to avoid links to non-existent pages.

Manual intervention would still be required in several cases:

  • the localized article is on external wiki - the link would have to be added manually
  • the localized article has different base name than the English page (Network configuration vs. Configuring Network (Italiano)) - best solution would be moving the localized pages to match the English page (this would be good anyway)
  • there are possible problems with redirects, I did not think of it yet


  • slower rendering of pages, higher server load (#ifexist is considered an "expensive parser function" [5])

Anyway, what do you think of it? Is it a viable solution?

-- Lahwaacz (talk) 13:53, 8 December 2013 (UTC)

The short answer would be the same I've given to Jstjohn in #Integrating Google searches into ArchWiki, however even if we could easily install extensions, maybe we should consider Help_talk:I18n#MediaWiki_translation_extension before this idea. I think you've never seen our Template:i18n on this wiki, which was practically the same except for the #ifexist check. It was in use before June 2012 and was deprecated by [6]: that discussion is full of arguments against its reintegration :D -- Kynikos (talk) 04:44, 9 December 2013 (UTC)
I like automatic solutions, I'm sure there are plenty of extensions that make this possible. The current solution is by no means automatic, even considering the Wiki Monkey bot plugin. We should at least have a solution to automatically check all pages on the wiki (or at least some specific namespace). The current solution relies on lists like Special:MostLinkedPages, which tend to overlap, and also in my opinion the plugin does not cover all cases. I already have several ideas on how to improve the algorithm, it's just the matter of putting it "on paper" - I think I'll open an issue about this on github... -- Lahwaacz (talk) 18:54, 9 December 2013 (UTC)
I have written a quite long post about redesigning the bot algorithm, but unfortunately it seems that I can't post it on github because markdown apparently supports only two levels of bullet lists :( -- Lahwaacz (talk) 07:41, 10 December 2013 (UTC)
No worries, we can easily discuss it here, after all we're doing it for this wiki's sake, it's nothing extraneous. Maybe you (or I) can create a bug report with a link to this discussion, just as a reminder for myself. -- Kynikos (talk) 14:35, 10 December 2013 (UTC)
Alright, I've started the discussion in Talk:Wiki_Monkey#Improvements_to_the_interlanguage_syncing_algorithm - feels like the right place for it... -- Lahwaacz (talk) 20:02, 10 December 2013 (UTC)
The discussion linked above has been closed, so I guess this can be closed as well... -- Lahwaacz (talk) 19:43, 1 March 2016 (UTC)

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 [7]). 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: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:

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 [8] (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 but to no avail, really weird. -- Kynikos (talk) 05:52, 7 July 2014 (UTC)
Found it! See [9] 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:
  1. Ask about the exact functionality of $wgRegisterInternalExternals
    • Possibly open a bug report to enable it here (still having FS#35545which from now on I will refer to as simply "The Bug" fixed would help)
  2. 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 addExternalLink method is called only from parts of the parser responsible for formatting the external links; then there is addLink for the internal (and interwiki) links. See also [10] 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 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 domain) takes 36.2MiB. Since 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)

Uncheck 'List redirects' search option. -- Karol (talk) 22:57, 2 August 2014 (UTC)
Ok. but this checkbox should be unchecked by default. -- wget (talk) 23:06, 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)
This could be a good idea, anything that avoids duplication is always welcome. -- Kynikos (talk) 14:12, 12 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 [11] 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 and expand 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[12])
-- 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. [13]. Have you also noticed the change or is it just my imagination? -- Lahwaacz (talk) 09:21, 6 February 2015 (UTC)

Look at this diff [14], you'll see a whitespace here.
Regretfully, whitespace/tab changes aren't highlighted when they're placed at the end of a line sometimes (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. [15].
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. [16]. 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:
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 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 managechangetags right 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 [17] [18] [19] :)
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)
Lahwaacz, thank you for answer. Good luck passing exams =).
Interesting solution. But ideally, I want corresponding categories to be side by side. In that case it would be easy to detect how much pages are translated and what is total number. — Agent0 (talk|contribs) 17:39, 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)
Half year late, but I've finally made a start: [20]. Now it should be just a matter of formatting the graph(s) into HTML/MediaWiki and implementing localized category names... -- Lahwaacz (talk) 19:34, 1 March 2016 (UTC)
Nice! Another TODO is to be able to change the roots with command-line arguments. Also, when formatting to MediaWiki, right-to-left languages may give some trouble, this is how I sort of managed that in Wiki Monkey. Preserving localized category names is easily done by parsing the previous ToC and storing the translations in a mapping object, e.g. [21] (should be case insensitive). Then I think implementing a guard against loops (including self-categorized categories) is another must todo. — Kynikos (talk) 02:39, 2 March 2016 (UTC)
Thanks for the tips, I think it's mostly finished now - except for the "also in" translations. I was thinking that they could be encoded directly in the wikitext using the HTML5 data attributes, similarly to how I currently configure the columns of the table - see the test page: User:Lahwaacz/Table of contents. -- Lahwaacz (talk) 14:56, 5 March 2016 (UTC)
Keeping the "also in" strings directly in the page sounds like a good idea to me, but I don't like the current version with the colon ("also in: [...]"), I prefer the one we're using now without the colon ("also in [...]")) :)
However can you test the script on the current Table of contents (Русский)? I get:
Traceback (most recent call last):
  File "", line 483, in <module>
  File "", line 464, in run
  File "", line 225, in format_row
    self.text += self.format_cell(*col) + "\n"
  File "", line 215, in format_cell
    output += " {} ({})".format(self.localize(title),[title]["pages"])
KeyError: 'Category:Email clients (Русский)'
Category:Email clients (Русский) is an empty category, so that's probably a corner case that hasn't been considered.
Kynikos (talk) 07:06, 6 March 2016 (UTC)
The bug was much more obscure, for some reason empty categories also have an empty "categoryinfo" field in the API response (see [22]), but it is fixed now. And the colon after "also in" was just an oversight :) -- Lahwaacz (talk) 07:48, 6 March 2016 (UTC)
It looks like a very neat job, apparently only the localization of "also in" is left to do (sorry I can't contribute at the moment, even though the code is crystal clear).
Then I've naively tried to use --toc-page=User:Kynikos/ToC_test but apparently the underscore is not recognized as a space, maybe the argument should be processed with ws.parser_helpers.title.canonicalize? (I know in production the config file would be used, but still... :P )
— Kynikos (talk) 04:33, 7 March 2016 (UTC)
Thanks for another bug report, the pages were actually returned by the API correctly but the error checking was too naive.
The most difficult part regarding the "also in" translations will be recognizing the correct language per-column and selecting good names for the data attributes. We could even encode the values using JSON or something like that, but that's an overkill for single-column pages. I haven't thought this through yet, so any suggestions are very welcome :)
-- Lahwaacz (talk) 07:20, 7 March 2016 (UTC)
{| id="wiki-scripts-toc-table" data-toc-languages="cs,en,..." data-toc-alsoin="také v,also in,..."
{| id="wiki-scripts-toc-table" data-toc-language-0="cs,také v" data-toc-language-1="en,also in" data-toc-language-#="...,..."
{| id="wiki-scripts-toc-table" data-toc-languages="cs:také v;en:also in;..."
(first split by ";", then partition by ":")
— Kynikos (talk) 02:08, 9 March 2016 (UTC)
In the end I've used something in between: data-toc-languages="cs,en" data-toc-alsoin="cs:také v, en:also in". The English "also in" is the default anyway, so data-toc-alsoin="cs:také v" leads to the same behaviour. And to simplify that further for single-column pages, the tag: prefix is optional if it corresponds to the language of the page that is being parsed, so e.g. data-toc-languages="cs" data-toc-alsoin="také v" would work as well on Table of contents (Česky). So if this last missing feature works as expected, I think it's ready for deployment :) -- Lahwaacz (talk) 20:38, 14 March 2016 (UTC)
Great! However I think we forgot one last detail... How do we convert (i.e. preserve) the existing translations to the new format? See [23] :) I suppose the only answer is parse the old table and create a temporary translation map... Sorry, I should have tested this earlier instead of waiting the weekend. Anyway I think that with this new script we can update the ToCs every day, since it uses generators which means many less queries; we could share the task like with ArchWiki:Statistics. — Kynikos (talk) 04:22, 20 March 2016 (UTC)
Actually, there is a trick that I forgot to mention: [24] :) Lahwaacz (talk) 07:49, 20 March 2016 (UTC)
Ooooh... never... mind... then :D I don't have much time now, if you want to go ahead with the conversion, help yourself ;) — Kynikos (talk) 08:08, 20 March 2016 (UTC)
Alright, it's done - except for the "also in" translations on some pages (the script will show the page titles in warnings). -- Lahwaacz (talk) 13:13, 20 March 2016 (UTC)
Well done, now I'm wondering if more translators or non-English readers (besides Russian) would prefer their ToC with the side-by-side comparison. — Kynikos (talk) 03:14, 21 March 2016 (UTC)

How to start using a bot

Hello again Kynikos! I've noticed your bot sorting maintainers in according to their activity, and I would like to use it in the same manner for members of ru translation team. Please, can you write a short step-by-step algorithm of actions I must do?

I've already installed wiki-monkey and arch-wiki in my browser, and also there's no need to provide code changes (I'm sure I'll find what I must change). Thanks in advance.

-- Kycok (talk) 20:38, 4 October 2015 (UTC)

Hey Kycok, actually the sorting plugin wasn't designed to be used by other users than me, so it's not even installed in the official Wiki Monkey release. However I've tried to patch it so it can be configured for other uses, try the following:
  1. Uninstall the version of Wiki Monkey that you've installed
  2. Install this version
  3. Add the <!--START AUTO LIST ... comments above and below the user list in ArchWiki Translation Team (Русский), you can copy-paste them from e.g. ArchWiki:Maintainers
  4. Visit Special:Preferences#wiki-monkey and search for "040ASCC" in the configuration object.
  5. Change the following:
            "040ASCC": [
            "040ASCC": [
                    "Sort translators"
                    "ArchWiki Translation Team (Русский)",
                    "The following Translators are currently inactive (less than 30 edits in the last 30 days):",
                    "automatically sort translators list according to recent activity"
Then click on "Save"
If everything went well, you should now see a "Sort translators" button in Special:SpecialPages that might or might not do what you suggested (I haven't tried it :P )
Note that the version I've made you install is not an official release, and 1) I haven't tested it and 2) I don't think it's going to be updated automatically the next time I make an official release. Hopefully I'll remember to inform you to uninstall it and install the next stable version when I get to release it.
If it doesn't work I'll test it better when I find some time.
Kynikos (talk) 10:30, 5 October 2015 (UTC)
Yup! It's working! :) Thank you a lot.
Just one important question, because I don't know all ArchWiki rules. Should I register a bot as a new user (, or I can launch it as Kycok with word "BOT" added in the edit summary?
-- Kycok (talk) 17:02, 5 October 2015 (UTC)
Wow, working at the first attempt!!? There has to be something wrong somewhere... :D
Nope, you don't need a bot account for sporadic automatic edits like sorting the list of translators. If however you're intentioned to use the bot to do large series of automatic edits on several articles (like dozens of them), then yes, it's better if you explain your plans first and then we decide whether to give you a bot account.
Kynikos (talk) 07:32, 6 October 2015 (UTC)
Ok, thank you again. Closing -- Kycok (talk) 12:22, 6 October 2015 (UTC)

Syncthing as a Backup Tool

Hi, you have added Syncthing to the list of Backup Applications here: I am a member of the Syncthing Core team and I would like that we do not encourage people using Syncthing as a Backup application, see also: I suggest removing Syncthing from the list of Backup applications, maybe we could create some list of "cloud" or "file synchronization" tools; that would make much more sense.


Hi Stefan, I noticed that the page was missing many applications that even have articles in this very wiki, so I thought I'd do a broad research and add everything I could find without filtering for the moment.
I haven't had the chance to try Syncthing yet, but it sounds similar in purpose to rsync and Unison, which are in the list as well and have a similar limitation when used for backups. I think the intro to Backup_programs#Rsync-type_backups explains it to some extent: only some applications do keep snapshots, but others are just blindly syncing folders, like Syncthing, so if used as backups they should be part of a custom-engineered system, for example syncing folders with a server that has its own local snapshot-creation system.
Of course I will respect your will, since you are a Syncthing developer (although a proof of your identity would be welcome :) ), so if you want it removed from the list, please just go ahead and do it.
However my idea would be to keep it there for the moment, and instead try to reorganize the article, since the current structure is very confusing. I was thinking of using some tables to better compare the features of every application, and if you instead wanted to give a hand in that direction it would be very appreciated!
Kynikos (talk) 07:47, 27 January 2016 (UTC)
If you want to create a "File synchronization" section in Backup programs, that's a better (temporary?) solution for me, however I've also started working on a possible completely new table-based solution in User:Kynikos/Backup programs: if it turns out to be a feasible thing, I'll propose to merge in in Talk:Backup programs. — Kynikos (talk) 12:31, 27 January 2016 (UTC)

Traditional compilation

Hi, thanks for fixing the double redirects to Kernels/Traditional compilation; I forgot to check. By the way, OT, you may want to check this brand new ruling - I can't remember how we managed to touch the topic once, but sure remember we did :) --Indigo (talk) 09:36, 17 April 2016 (UTC)

No worries, I just blindly fix double redirects with Wiki Monkey, it's a matter of clicking on a button ;)
Thanks for the link, although I had already read that... But you know the famous quote, often attributed to Gandhi (although w:Mahatma_Gandhi#Misattributed says no): "First they ignore you, then they laugh at you, then they fight you, then you win." We just happen to be at step 2 there... Be optimistic, there are corners of the world that have already made it out of the Dark Ages [25] :D — Kynikos (talk) 10:05, 17 April 2016 (UTC)
Darn, what bright news :D Given one of the victories quoted in your link was in MA, which happens to be home of the FSF, I believe it is just a matter of time it renames itself to F{r,l}ying Spaghetti Foundation, and I now wonder what RMS, who is already ministeroni of the Church of Emacs, chooses for his next driver's license :D (gotta quote him once on top: "I did write some code in Java once, but that was the island in Indonesia.") --Indigo (talk) 07:48, 19 April 2016 (UTC)
Lol :) I won't reply further or I'll have to ban ourselves for spamming, but remember I'm always happy to chat about this stuff by email or other channels ;) — Kynikos (talk) 08:18, 19 April 2016 (UTC)