Difference between revisions of "User talk:Kynikos"

From ArchWiki
Jump to navigation Jump to search
m (Thanks for helping me out with the style issues :))
Line 300: Line 300:
  
 
::Oh, thanks, it's fixed indeed. [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:25, 20 July 2015 (UTC)
 
::Oh, thanks, it's fixed indeed. [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:25, 20 July 2015 (UTC)
 +
 +
== Yocto ==
 +
 +
Thank you for helping me with my style issues on the [[Yocto]] page [[User:Soderstrom|Soderstrom]] ([[User talk:Soderstrom|talk]]) 08:59, 6 August 2015 (UTC)

Revision as of 08:59, 6 August 2015

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 archlinux.org. At the same time there are national wikis as well, at different stages of development. In my case this is archlinux.se, 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 wiki.archlinux.se 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 wiki.archlinux.org, 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 mediawiki.org: [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

Disadvantages:

  • 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)

Russian table of contents

As I know, your bot must add new categories in it during auto-updates, but it isn't. I've translated List_of_applications/Science: english article has category Mathematics and science, and I've created page with category Mathematics and science (Русский), there was April, 28. Since then that category wasn't added to our TOC. What should I do? -- Kycok (talk) 17:30, 5 May 2014 (UTC)

Eheh adding a page to a category is not enough to create the actual category. As you can see, the link to Category:Mathematics and science (Русский) at the bottom of List of applications/Science (Русский) is red: this means that the category page doesn't exist yet, you will have to create it explicitly, that's why the bot can't find it.
Instead of doing it myself, I'll teach you how to do it, so you'll be able to repeat it in the future if needed:
  1. click on the red link, thus opening Category:Mathematics and science (Русский) for editing
  2. also open Category:Mathematics and science: as you can see it's categorized under Category:Applications
  3. in Category:Mathematics and science (Русский), add [[Category:Applications (Русский)]] and then save the page
And that's it, the next time I'll run the bot (Sunday), the category will be added to the tree :)
-- Kynikos (talk) 13:18, 6 May 2014 (UTC)
Thanks a lot for explanation. I think you can move it to the top for those, who'll be searching that information on your page (as me) -- Kycok (talk) 15:41, 6 May 2014 (UTC)
Sorry to jump in, but there is one more thing Kynikos did not mention - when creating a localized category, it will be necessary to also add the interlanguage links into all pages in the "family", as for regular pages.
Wiki Monkey has a plugin for the synchronization of these links, but (with current implementation) it is necessary to create at least the initial connection manually - meaning at least interlink the newly created category with the English category, the bot can do the rest. Kynikos, we should clarify the guidelines for this... recommend creating a bot request?
-- Lahwaacz (talk) 16:49, 6 May 2014 (UTC)
Done. So, more correct instruction is to copy all english wikitext and fix interlanguage links -- Kycok (talk) 01:05, 7 May 2014 (UTC)
Oops, sorry for not being exhaustive this time, @Lahwaacz you're right of course, and @Kycok you've done the correct fixes.
The complete checklist for a translation is in ArchWiki Translation Team: maybe it's not the best place, but it's linked from ArchWiki:Contributing#Translating.
@Lahwaacz: about the clarification, did you consider ArchWiki Translation Team, Help:Style#Interlanguage_links and Help:I18n#Guidelines? What improvements/clarifications do you think can be done exactly? Yes, suggesting to request a bot intervention may help, maybe we could add it in ArchWiki Translation Team?
-- Kynikos (talk) 04:21, 7 May 2014 (UTC)
I did not look for it before, but since the "translating" of categories is the same as for regular pages, this should be enough...
The current implementation of the interlanguage syncing algorithm is rather unfriendly to recommending it, I don't know how to write "interlink the new page with the original both ways, the bot will do the rest" understandably. We might wait for the improvements (the part about watching Special:NewPages) if it is still planned...
-- Lahwaacz (talk) 15:03, 8 May 2014 (UTC)
Yes, it's still planned (#148) but it's a big job, let's wait until I've implemented it then. -- Kynikos (talk) 04:01, 10 May 2014 (UTC)
Sorry, I did not understand how to translate categories in Table of contents. How can I do this, if it will be overwritten next time by bot? — Agent0 (talk|contribs) 10:01, 22 July 2015 (UTC)
You can manually translate each link in Table of contents (Русский) by using the alternative text field ([[:Category:Demo (Русский)|Alternative text]]) and the bot won't overwrite it, see also Talk:Table_of_contents_(Русский)#Automatic updates and translation of links :)
Thank you for all your hard work!!
Kynikos (talk) 10:07, 22 July 2015 (UTC)
Thanks for reply. I translated it. — Agent0 (talk|contribs) 12:49, 22 July 2015 (UTC)

MediaWiki and help pages centralization

MediaWiki tries to centralize help pages, many links in the interface now lead to https://mediawiki.org (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.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:

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 https://wiki.archlinux.org/api.php or https://wiki.archlinux.org/index.php as internal, which is very unfortunate.

-- Lahwaacz (talk) 07:26, 6 July 2014 (UTC)

I'd even say that every https://wiki.archlinux.org 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 [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 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)

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 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 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)

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)

Broken page

Hi, regarding this page: Window_Manager_(العربية)

There seems to be an error which breaks the rendering of the MediaWiki interface on that page, e.g. the page/discussion/edit buttons at the top are rendered improperly. It's possibly caused by the dir=rtl divs interleaving the Article summary templates, do you have an idea how to fix that?

-- Lahwaacz (talk) 16:35, 19 July 2015 (UTC)

I think this fixed it, there were 3 non-closed divs and MW didn't like it (and for once I agree :P ). – Kynikos (talk) 03:50, 20 July 2015 (UTC)
Oh, thanks, it's fixed indeed. Lahwaacz (talk) 07:25, 20 July 2015 (UTC)

Yocto

Thank you for helping me with my style issues on the Yocto page Soderstrom (talk) 08:59, 6 August 2015 (UTC)
https://wiki.archlinux.org/index.php?title=User_talk:Kynikos&diff=prev&oldid=390168
wiki.archlinux.org
crawl=CC-MAIN-2019-47
90220
application/http; msgtype=response
sha1:7DLUYWQ46YAXKYOJAQHBHVFVFVUA726Y
<urn:uuid:5da0ecae-d416-4ad7-b05a-68a88e19752e>
2019-11-13T02:34:16Z
138.201.81.199
text/html
sha1:NOS5A4O27FHJISUOBW7E2IRFFEDV5DPG
<urn:uuid:bb73caaa-a3f6-434f-8d13-a23fb39a3fc9>
https://wiki.archlinux.org/index.php?title=User_talk:Kynikos&diff=prev&oldid=390168
response
<urn:uuid:e249e3c8-5c70-438a-8399-d77c20fee879>
isPartOf: CC-MAIN-2019-47
publisher: Common Crawl
description: Wide crawl of the web for November 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-168.ec2.internal
software: Apache Nutch 1.16 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/