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!
- 1 QuickVZ
- 2 Xyne-related page edits after Powerpill, Bauerbill... discontinuation
- 3 Where should translations go?
- 4 Text shift in discussion answers
- 5 VirtualBox article rewrite
- 6 Integrating Google searches into ArchWiki
- 7 Crazy idea about interlanguage links
- 8 Anomaly in list of categories
Systemd / Transmission
I understand the reversion of my comment. Unfortunately the only proof I have is the email they sent out to all of their customers, myself included, and my subsequent conversation with them. Hopefully they'll update their official website soon. If not then I'll check on April 1st that they really have gone down and just remove them from the list then.
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)
VirtualBox article rewrite
I'm currently rewriting the VirtualBox article and I've some question about the latter.
In the Related section of that article, there is currently two different articles which are looking exactly the same regarding the subject they are dealing with:
- Installing Arch Linux from VirtualBox: this one is really outdated and has been marked as is for ages. I think it could be removed. If you agree, could you request its deletion or do it by yourself (I think I haven't the required right to achieve that).
- VirtualBox Arch Linux Guest On Physical Drive: this one is rather recent only initscripts' and grub legacy mode should be replaced by systemd and grub2.
Also I've found a page dedicated to systemd services which are completely unrelated. I've found a service related to VirtualBox, I think the later should be removed from that section and integrated to the main VirtualBox article (this is what I'll do).
Also I wonder why even this systemd/Services section has ever been created. It has unrelated stuffs and each of them should be located to its related article. The problem is similar with sections of the systemd main article.
- Hi Wget, thank you for your will to take on this task! After having a look at the current status of those articles, I agree that there are indeed many improvements that can be done:
- I confirm that Installing Arch Linux from VirtualBox and VirtualBox Arch Linux Guest On Physical Drive practically cover the same topic, however they do it for two different purposes: the former allows installing Arch Linux on a physical drive from VB, the latter allows booting an already existing "physical" system from VB; IMO the best thing to do in this case would be to merge the two articles while keeping intact and clear the distinction of the two scenarios (i.e., some rewording would be required on VirtualBox Arch Linux Guest On Physical Drive); maybe a new title could be created for the merged article, and the old ones should be redirected there, not deleted.
- About systemd/Services I think you're right, those units should be moved to the respective articles, if existing: if a list of services not provided upstream is required to keep track of the status of the respective packages, systemd/Services should be moved to the DeveloperWiki namespace and it should contain only a list of links to the articles where the services have been moved. It would be great if you could start a discussion on Talk:systemd/Services about this. Regarding the VB service you can safely move it to VirtualBox.
- About Systemd#Running DMs under systemd, both it and Systemd#Native configuration are already properly marked for merging/moving/deleting, they're just waiting for somebody to give them a bit of love ^^
- -- Kynikos (talk) 02:16, 30 September 2013 (UTC)
- Hi Kynikos,
- Thanks for your fast reply. I've just begun to make the adaptation, articles merge, we agreed on. But after spending some times to the article, I realized that the Wiki's style rules don't explicitly define how parts of commands that have to be adapted must be formated (or maybe I haven't found it yet ;-) ). An example is worth a thousand of words:
# dkms install vboxhost/<virtualbox-host-source version> -k <your custom kernel's version>/<your architecture>
- In which format do I have to put <the strings that must be replaced/adapted>. I don't even know if we have to surround them with angle brackets < >.
- Wget (talk) 22:00, 30 September 2013 (UTC)
- Help:Style/Formatting and Punctuation will give you all the answers you need, in particular Help:Style/Formatting and Punctuation#Pseudo-variables in file/command line contents deals with your example.
- Sorry if I can't give you feedback for your edits now, but I'm incredibly busy, I'll get there in the next days! Meanwhile if you have more questions don't hesitate to ask :)
- -- Kynikos (talk) 14:54, 1 October 2013 (UTC)
Hi Kynikos, Just to bring to you some updates. I'm still on this rewrite. It is longer that expected as I need to recheck all assumptions written in the documentation (and I needed to wait for the 4.3 release). I'm gonna make some subpages, as proposed in the discussion page of VirtualBox Extras. Do you know if some warning templates are available to indicate that the page is currently being rewritten? -- wget (talk) 19:59, 6 November 2013 (UTC)
- Hey wget, thanks for the update, I think just using Template:Stub with a proper description will serve the purpose. -- Kynikos (talk) 08:50, 7 November 2013 (UTC)
Kynikos, The rewrite makes some progress, but I'm still spending a huge time at verification and tests. I put the content from VirtualBox Extras to the main VirtualBox article. Could you proceed to deletion of VirtualBox_Extras? Thanks! (The main VirtualBox article will be clearer when I will have finished the rewrite and a dedicated subpage might be unneeded) -- wget (talk) 20:47, 12 November 2013 (UTC)
- Done, it's always preferable to redirect instead of deleting when possible :) I'm trying to follow your changes, I think you're doing a great job, keep up the good work!! -- Kynikos (talk) 08:48, 13 November 2013 (UTC)
Hi Kynikos, regarding the Virtualbox article rewrite, I wonder if you could remove this article Installing_Arch_Linux_from_VirtualBox since it does not contain any relevant content (it is only speaking about creating an Arch Linux VM stricto sensu, without adding much information. Install steps for Arch Linux guests are already covered in the main article. Can we remove that article and, if needed, redirect it to VirtualBox. Thanks. -- wget (talk) 22:35, 30 December 2013 (UTC)
- What about my observation above about it and VirtualBox Arch Linux Guest On Physical Drive? (02:16, 30 September 2013 (UTC), first bullet point) I still think Installing_Arch_Linux_from_VirtualBox has a goal that's not covered in VirtualBox. -- Kynikos (talk) 12:02, 31 December 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  and , 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.
- 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)
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: , . 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 (
#ifexistis considered an "expensive parser function" )
Anyway, what do you think of it? Is it a viable solution?
- 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 : 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)
- 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)
Anomaly in list of categories
in  there is an anomaly in the list, which prevents Wiki Monkey to update filter preview:
1731. Invalid title with namespace "Category" and text ""
I can't think of any reasonable explanation since
[[:Category:]] does not work.
Another thing, is there a reason why deleted pages are in the list of most linked-to pages even though they are not linked or transcluded?
- Weird, Wiki Monkey expects to find a link in those list items, so it was just crashing there. From the next release it won't blindly assume there's a link anymore :)
- Maybe a category with an empty title was created with a version of MediaWiki that was still allowing it? It's unlikely that they put it there by default for a mechanism that kind of prevents its creation, because other wikis don't have it, e.g. .
- About the second question, I think you're talking about deleted Categories, not simple pages, as no pages with 0 backlinks appear in Special:MostLinkedPages. Assuming you're talking about Special:MostLinkedCategories then, most (if not all) of the red links that you see there are former "wanted" (not "deleted") categories, which are likely cached in a special database table for which deletion of entries has never been implemented perhaps for the danger of breaking something else? MostLinkedCategories would then query that table without filtering the results with 0 backlinks: I've got no idea why, there could even be no reason at all and it just happens to have been implemented like that, waiting for somebody to submit a patch ;)
- -- Kynikos (talk) 15:52, 25 December 2013 (UTC)
- I was talking exclusively about categories. Thanks for pointing out that Special:MostLinkedPages (and also Special:MostLinkedTemplates) are OK - this is really weird, so I've submitted a bug report.
- I also found this commit, which is probably behind the error description produced in the list.
- -- Lahwaacz (talk) 22:55, 25 December 2013 (UTC)
Systemd / Transmission
In this diff [] (/usr/lib/systemd/system/transmission.service in transmission-cli 2.82-1 seems to invoke "/usr/bin/transmission-daemon -f --log-error"), systemd does invoke "transmission-daemon" as usual, but the user has to use "transmission" when invoking systemd/systemctl. Idomeneo1 (talk) 18:22, 23 February 2014 (UTC)
- Thank you for clarifying, "transmission" is not "invoked" by systemd then, it's just the name of the service, as I've further remarked with , I think the article is clear enough now about that, if somebody tries to start a "transmission-daemon" service they'll just get a simple error anyway, and they'll read the article again more accurately ;) -- Kynikos (talk) 03:32, 24 February 2014 (UTC)
- The problem with this is people are not going to know that this service is not called by what they would expect it to be called. In fact the only place where "transmission" occurs without a modifier is the config folder - for the GUI, not even for the daemon. Daemon names are generally marked in some way, as the normal transmission-daemon command is, and users are not going to come up with the idea on their own, that calling "transmission" on systemd/systemctl doesn't following any usual pattern.
- "they'll read the article again more accurately" - Now the article doesn't say this at all, and an error message is not going to give them any idea what the problem is.
- Idomeneo1 (talk) 14:41, 24 February 2014 (UTC)
- The problem is that people who consult the wiki do need this spelled out, because if they think they're starting a transmission-daemon, as systemctl itself does, it becomes counterintuitive to suddenly be "starting" transmission. If the wiki administrators have been rehashing this stuff ad nauseam, the people who actually consult the wiki do come from other distros and need these things spelled out.
- Idomeneo1 (talk) 14:54, 25 February 2014 (UTC)
- Users that are confused about this need to read about systemd to understand what a service/unit file is and does. There is a significant difference between running a program and starting a systemd service. If the reader is familiar with systemd and what a service/unit file is, the transmission-daemon/transmission thing is not all that counter-intuitive.
- I do not know what you mean by this:
If the wiki administrators have been rehashing this stuff ad nauseam
- -- Jstjohn (talk) 01:54, 26 February 2014 (UTC)
- @Idomeneo1: I'd like to know if you've read of somebody being actually confused by that, or if you're just guessing. Because to me the name of the service is already "spelled out", unless we want to start trying to prevent users from misreading words everywhere in the wiki by adding a note whenever there are two "things" with similar names.
- I also don't get how the fact of coming from another distro could make a person more likely to misread a word, as if only Arch users had the ability to correctly read names of systemd services.
- Anyway, I didn't want to get so far for such a little detail, but at this stage your next viable option is to start a poll in Talk:Transmission, otherwise we'll never settle this.
- -- Kynikos (talk) 02:01, 26 February 2014 (UTC)
- It did confuse me, in fact. Moreover, at the time the Transmission article was such mess, I was consulting Google, which also threw transmission-da in the mix. Prior to that I had only used the GUI version, which requires minimal configuration. I don't think my experience was exceptional, but of course it would be a simple matter to dismiss someone who would be confused by an confusing article as a noob.
- Ntpd, wicd, dhcpcd, xdm, gdm all use "expected" names for systemctl. Netctl and dropbox discuss their differences in their articles.
- It is those little, easily-overlooked details that make things go or not go, that need to be pointed out.
- Idomeneo1 (talk) 02:44, 26 February 2014 (UTC)
- I wasn't really objecting the "big purple template" itself, just what was inside, however after all if the note has to be there, it's better to keep it without the Note template.
- About the systemctl commands I'm tired to fix, I was referring to Help:Style#Daemon operations, according to which I should remove them again.
- -- Kynikos (talk) 01:17, 1 March 2014 (UTC)
- But if they work differently, i.e. having to specify the user or not, this needs to be pointed out in some way. With daemons, command-line commands and systemctl calls can often be used interchangeably, and where they don't follow the same rules, this needs to be said - this was evidenced in the article itself, which had the systemctl usage wrong.
- Idomeneo1 (talk) 01:33, 1 March 2014 (UTC)
- I don't think we're talking about the same thing: what conflicts with Help:Style#Daemon operations (and I invite you to actually follow the link and read what's written there) is the systemctl example itself, not the mention of the service. However I've taken the time to fix the article once again, I hope it makes what I'm saying clearer for you. -- Kynikos (talk) 02:29, 1 March 2014 (UTC)