Help talk:Style

From ArchWiki
Revision as of 09:00, 9 July 2014 by Lahwaacz (talk | contribs) (Preferred subpage method: re)
Jump to navigation Jump to search

Read this first

Help:Style is an official document of the ArchWiki, and it is actively monitored for malicious, unapproved, or poor quality edits. This is necessary to ensure sufficient stability over time, since frequent, undiscussed changes to its rules would defeat the purpose of the guide itself.

It is probably needless to say that the active supervision of the article makes this very talk page the most important and effective place for discussing every possible improvement to the guide, from the correction of small typos to major changes like the introduction of new rules. Every report or discussion is welcome and will be answered as soon as possible. However, if an existing style rule is under dispute, its current state remains enforced until it is changed, if that ever happens.

This guide was born after several months of discussions among the administrators and the most active contributors at the time, and it is a compromise among their ideas and those of who has been contributing until now. While new ideas and proposals that are coherent with the guide will probably be accepted and implemented, it is also likely that the requests that aim to radically change the way a particular style issue is already addressed will be discarded. We all must acknowledge the fact that it is reasonably unrealistic to think that all the ArchWiki users will ever completely agree over all the style rules, that is why it becomes necessary that final decisions be made by the administrators: we hope that this concept will be peacefully accepted by everybody, so that we can all collaborate in a more constructive way.

Thank you for reading this notice and for contributing to the ArchWiki! -- The ArchWiki Administrators 21:27, 14 January 2012 (EST)

Tip: A way to speed up the addition or modification of style rules is to provide some text that, if approved, can be directly copy-pasted in the guide, just like patches work for bug reports.

Change Edit Summary label and possibility to make it mandatory

All edits to articles should be accompanied by some words in the summary filed, answering the question "Why did you edit the article?". "What", "where", "when" and "how" are self-explained by the diff itself, it's redundant to add them. An explanation is not mandatory in talk pages, where the "why" should be already evident. Remember that links are allowed in the summary field, so it is allowed to point to an existing discussion. -- Kynikos 09:32, 3 May 2011 (EDT)

Maybe we could submit a bug to request the change of the word "Summary:" to "Reason for editing:" next to the input in the edit page itself? -- Kynikos 11:33, 3 May 2011 (EDT)

Would it go directly upstream? The Polish wiki has something like Summarize the changes [you've made to the article]. Wikipedia has Edit summary (Briefly describe the changes you have made). They all deal with what is being changed, not why - we need to fix this :-) -- Karol 12:04, 3 May 2011 (EDT)
Done: FS#24075, remember you can vote it. -- Kynikos 12:57, 3 May 2011 (EDT)
Any wiki admin can change this message (aside: can you view Special:AllMessages?) I think it might be more fitting to include this as an addendum to the copyright notice instead (text above the summary field). Perhaps we should also consider making the edit summary mandatory (i.e. prevent saving with a blank summary). -- pointone 22:55, 4 May 2011 (EDT)
Nice, I can see that page, I didn't know that ^^ Maybe I should close the bug request then. Anyway I'm quite sure that only appending this recommendation to the copyright notice would make people start ignoring it very soon (as it happens with road signs eheh): I'm still in favour of changing the word "Summary", as it's misleading. Making the field mandatory could be a great idea instead, but for what I've seen until now, if the edit page returns an error, it forgets about the editing done, and it would be quite annoying (the textarea could be easily repopulated echoing $_POST['...'] instead of recovering the text back from the database; I have only tested this when trying to edit a page that has been edited by somebody else meanwhile). -- Kynikos 06:15, 5 May 2011 (EDT)
(Well, doing it in javascript would solve the problem, though using JS is not very wiki-style it seems) -- Kynikos 06:17, 5 May 2011 (EDT)
When saving an edit that conflicts with another, your changes are saved. MediaWiki presents you with two text areas: one contains the page contents and the other contains your edit.
Either way, a quick Google search reveals User:DieBuche/forcesummary.js and Wikipedia:Wikipedia:WikiProject User scripts/Scripts/Force edit summary as two possible solutions. There also is a user preference option under Editing > Advanced options > Prompt me when entering a blank edit summary -- I wonder whether we can enable this option by default as a less-intrusive solution.
-- pointone 09:16, 5 May 2011 (EDT)
Uhm it always looked like I lost my changes everytime I had edit conflicts (always easily recovered with the back button), anyway it could be that I didn't look well.
About the main topic, I would first try just to change the Summary text, anyway if you want to go the JS way immediately, do it in a way that the user understands that he has to answer the question "why", not "what", otherwise all edit summaries would probably be filled with "added section", "corrected code", "deleted section" and so on (well, those are summaries in the end, and that's what the form requests literally atm). -- Kynikos 11:07, 5 May 2011 (EDT)
I think it's also OK to combine 'what' with 'why' e.g. 'removed outdated links'. I'm not a native English speaker, but it sounds more natural than 'links were outdated'. -- Karol 11:50, 6 May 2011 (EDT)
Of course it's also ok, anyway I'm not a native speaker either, but if a label says "Reason for editing" it comes more natural to me to write "links were outdated". This system should also exploit a bit of psychology afterall. -- Kynikos 12:56, 6 May 2011 (EDT)
<facepalm> Of course you are absolutely right ... I - ummm - forgot that we wanted to change 'Summary' to 'Reason for editing'. Sorry about that. -- Karol 19:58, 8 May 2011 (EDT)
Since the bug got closed as 'Upstream', do we go upstream with this? -- Karol 19:58, 8 May 2011 (EDT)
I am curious whether this has been discussed upstream already... I have no problem with making the change on our end, since every wiki handles summary policy differently (as pointed-out above in examples). -- pointone 22:46, 8 May 2011 (EDT)
Well you are the one in charge here, you can decide what to do now ;) -- Kynikos 05:53, 9 May 2011 (EDT)
The style part of this discussion has been implemented in the guide. I'd still be interested in changing "Summary" to "Reason for editing", anybody else? -- Kynikos 15:32, 21 September 2011 (EDT)
Going upstream would benefit more that just our wiki, as mediawiki is a pretty popular piece of software. +1 from me. -- Karol 16:45, 21 September 2011 (EDT)
The relevant system message is MediaWiki:Summary. I would suggest that the word "Summary" itself remain, as it is referenced in other locations and the documentation. My vote is for addition of an explanatory subtext à la Wikipedia. (Summary: (Briefly describe the changes you have made)). -- pointone 13:50, 22 September 2011 (EDT)
Cooool, that's the way to go! +1000 XD
Some ideas:
  • Briefly explain the reason for the changes you have made
  • Briefly explain the reason for your edit
  • Briefly explain the reason for your changes
  • Briefly explain the reason why you edited the page
-- Kynikos 15:55, 22 September 2011 (EDT)
I think a combination of using explanatory text (I like something such as "Briefly explain the reason for your changes" from your suggestions), and investigating how to set "Prompt me when entering a blank edit summary" user option by default would make it more noticeable and be a great start here. Emiralle 12:56, 15 October 2011 (EDT)
I'd like to make the edit summary strictly mandatory (meaning that a blank summary field won't allow submitting the edit): pointone mentioned some possible methods for doing this in the first part of the discussion, I'm just adding some more references as reminders (don't know exactly what to do with them yet... :P ): [1] (see "forceeditsummary"), [2], [3]. -- Kynikos 15:01, 20 October 2011 (EDT)
For the moment I've changed the label to:
Summary (what you did and why):
as you can see when opening a page for edit, I hope it's ugly and annoying enough to be noticed by many >;)
-- Kynikos (talk) 11:37, 11 July 2013 (UTC)
The edit box has been moved to the right, so it's easy to spot that something's different. I like it, good job, Kynikos. -- Karol (talk) 19:14, 12 July 2013 (UTC)
About making the Prompt me when entering a blank edit summary option enabled by default, this is what has to be done:
  1. Have FS#35545 implemented
  2. Edit MediaWiki:Missingsummary and make it more visible and formative
  3. Add the forceeditsummary option to the default user preferences as described in mw:Manual:$wgDefaultUserOptions
-- Kynikos (talk) 03:06, 13 July 2013 (UTC)

Article summary templates

See Help talk:Style/Article summary templates.

Category pages - tree or otherwise?

The ArchWiki category tree was originally designed as just that: a tree. I disagree with the point: A category can be categorized under more than one category, provided one is not ancestor of the others. I believe that categories should themselves be categorized under only a single category. Non-overlapping categories should be devised in cases where one category could belong to many. Related categories can be listed on the category page itself. -- pointone 10:39, 23 September 2011 (EDT)

As noted at the top of Table of contents, Category:Secure Shell is a good example: if we can solve it we can really try to avoid categories with multiple parents in general, which is something that I don't like either. The problem is that Security could hardly be child of Networking, and vice versa, so either we put Secure Shell only under one of them, or for example we split Security in two categories, one under Networking, the other not, and put Secure Shell under Networking->Security. Of course we could also split Networking instead, but it would probably be less natural. -- Kynikos 11:43, 23 September 2011 (EDT)
Is there any decision on this? I would like to add Category:Package development as a subcategory of Category:Package management. Currently it is only a subcategory of Category:Arch development. But there is no point in me doing that if it is just going to be undone. Otherwise I would add a manual link from Package management (which may have helped me find what I was originally looking for) and probably a reciprocal one back the other way. But I feel that is more work than necessary and when looking for information on the wiki I expect the categories to work this way instead.
 Why were the Arch wiki’s categories originally designed as a tree? Why do you prefer that categories only have a single parent category, especially when article pages do not have to? Vadmium 10:52, 26 October 2011 (EDT).
No decision yet, the current style rules allow multiple parents also for categories, so you can implement your idea, don't worry now whether it will be undone or not in the future. Just remember to update Table of contents or Talk:Table of Contents (I don't remember which one is the most up-to-date) and to link to this discussion from the Edit Summary.
In general, a tree-like structure is the "ideal goal" because it looks simpler and tidier than having "converging branches", thus helping organizing the articles in a more natural way and also making maintenance easier. However it may be hard to put into practice indeed, so this discussion is probably going to last long...
-- Kynikos 12:59, 27 October 2011 (EDT)
Although not ideal, we can't really help having converging branches in practice, I'm closing this discussion. -- Kynikos (talk) 03:56, 5 July 2014 (UTC)

Style vs. Usability

Commenting on: Help:Style#Daemon_operations and Help:Style#Official_packages

Deprecating installation instructions and the method of adding deamons to the DAEMON array is causing a higher than normal amount of questions on how to do this in the IRC channel. Perhaps this can be reconsidered, or at least be reconsidered for critical articles like the beginner's guide, the dbus article, the official installation guide, the various graphics driver pages (ATI /NVIDIA) etc etc. These are often browsed from CLI during installation and should thus be as complete as possible, having to follow links around and back from a CLI browser is no fun.

And in general: Having to look up the method of applying a change mid-article kills the flow of the article, users have to browse around to find a system-critical method on a different page.

This would be fine if the action involved wasn't so important, or if the linked information was either:

  • a small non-critical note
  • a large block of text requiring separate attention

but these actions are system critical. We don't want to create confusion in guide-nature articles. --stefanwilkens 18:18, 10 January 2012 (EST)

[This post had several replies that diverged into separate branches, highlighted with the different subsections below. -- Kynikos (talk) 04:32, 27 July 2013 (UTC)]

Improve visibility of installation requests

[This sub-discussion stemmed as one of the several replies to #Style vs. Usability. Note that you may find some references to other sub-discussions that have been closed and removed. -- Kynikos (talk) 04:32, 27 July 2013 (UTC)]

This debate ended up very lively with strong arguments from both sides, I'd like to present a new side to the same argument. I much enjoyed the fact that the "old" method of signifying an installation action provided a clear optical action point; compare if you will:

$ pacman -S package1 package2

NTPd can be installed with the package ntp, available in the Official Repositories.

The "old" method clearly signifies action should be taken, the new method suggested in the style documentation is far easier to miss in a large document. Furthermore, this new method reads more as a tip or a notice than an action statement, is that desirable or recognizable?

I believe this is similar to what Kynikos suggested a few blocks up, on 12:30, 11 January 2012 (EST)--stefanwilkens 15:42, 17 January 2012 (EST)

Yeah I suggested that only as a possible compromise, although I still prefer the current phrasing. You're perfectly right, those who are used to reading only the blue parts in the articles will miss the installation parts with these style rules. But do we really want to accomodate to their needs? Words, even if on a white background and in variable-width fonts, have a definite, most often useful meaning, they have not been put there for aesthetic matters or by mistake. I don't think your argument is convincing, but let's see if somebody else has something to add. -- Kynikos 16:39, 17 January 2012 (EST)
Accommodation to the needs of experienced users (dislike reading hand-holding articles) is brought up as an argument a few blocks up from here. Why accommodate one group over the other? This is likely a question of who the target audience is. Is there a guideline on this at all? Is our documentation intended to let the novice users successively install / operate Arch Linux and anything we may describe in our WiKi or do we set the guideline that we expect more?
I think I may have answered my own question as I wrote this, but for the sake of consistency. What is the target audience?
As for the style, I would be inclined to add indentation or something else to attract attention to these to-be-installed lines. Visited links on our style turn grey, the line really does blend in with the article if all links in it are visited previously. Would additional attention be acceptable?--stefanwilkens 18:14, 18 January 2012 (EST)
The information is still available on the wiki and linked to when relevant. In my opinion, duplicating instructions everywhere doesn't help new users. Instead, it provides them with many sources of incomplete and often out-of-date/inaccurate information rather than directing them to an high-quality article.
I understand that there's a steep learning curve, but hand-holding instead of teaching just prolongs it. Arch was my first experience with Linux and I had zero command-line knowledge. I ended up doings lots of reading (mostly the wiki at first, eventually other documentation) and worked through the issues I encountered. At that point the Beginners' Guide was a huge mess because it had many step-by-step branches (instructions for installing a dozen DEs/WMs and mouse cursors/themes!).
If we just provide copy-and-paste commands everywhere we don't provide much opportunity to learn, and just teach users to turn to the forums or #archlinux at the first sign of trouble (instead of relying on the community as a fallback when they've already done research and tried to figure it out for themselves). Relevant:
Linking to well-written and maintained articles makes it much easier for someone to go from being a new user to an experienced one; you only have to learn how to install/remove/downgrade a package once (likely just when you need to do it) and then you're set forever. It will make it harder for people who don't want to read or learn and just enter commands copied from the wiki, but I don't think we should encourage that.
Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.
- thestinger 21:21, 18 January 2012 (EST)
This comments on the content and overall tone of the article. Both "old" and "new" suggested methods of displaying the information contain equal content, I don't think we're loosing content or significantly avoiding hand-holding behavior at all with this new style. I accept that my initial argument on the removal of terminal style installation instructions has passed, but that's not what I'm trying to talk about in this section.
My debate here is that of readability, how to best present this information to a reader. Regardless of article tone, what optical structure is best used to signify key action points in the article. See the example 4 blocks up and take note of the significantly reduced visibility of these actionable points (something your link talks about). If we are to write actionable documentation, should we then not make sure that the directly actionable sections of the documentation are prominent?
Open up any textbook, examples are always provided in colored blocks, other fonts, indented notation or preceded by colored or otherwise optically attracting constructs. The suggested style blends in with an article, especially when the links in it are marked "visited" (grey) --stefanwilkens 07:19, 19 January 2012 (EST)
The current package installation style is now very well established, and users have got used to it, I haven't read negative feedback for a long time. Visibility of installation requests could still be enhanced by #Pkg and AUR templates: add icon, make them look different, which is still interesting. Closed. -- Kynikos (talk) 04:06, 5 July 2014 (UTC)

Visited links color

[This sub-discussion stemmed as one of the several replies to #Style vs. Usability. Note that you may find some references to other sub-discussions that have been closed and removed. -- Kynikos (talk) 04:32, 27 July 2013 (UTC)]

Changing the color of visited links has been in my todo list for some time, maybe it's time to submit a bug for that: I'd like to see a purplish color, I tried something like #606, #70b, #74b. More ideas? Objections?

-- Kynikos 08:33, 19 January 2012 (EST)

Note that interwiki links already become purple (albeit still too greyish?) when visited: wikipedia:Main Page wikipedia:Main Page. -- Kynikos 15:25, 24 January 2012 (EST)

I'd also like to request that links remain bold even when they are in indented paragraphs (#bodyContent dd > a {font-weight:bold;} ?) -- Kynikos 11:46, 29 January 2012 (EST)

Completely agree. Also, I think, color should be different from one of interwiki links. --AlexanderR 23:54, 29 January 2012 (EST)
Do you mean of a completely different color? Can you be more specific or give an example? In any case if there should be a difference in color among links, it should distinguish internal from external links (including interwiki).
However I think that black for normal text, blue for links (internal or external), purple for visited links and black on cyan for code may be already enough.
-- Kynikos 07:11, 31 January 2012 (EST)
>> Do you mean of a completely different color?
No, a bit darker shade than #606 (or, maybe even a bit more rich) would be perfect. --AlexanderR 00:29, 4 February 2012 (EST)

Pkg and AUR templates: add icon, make them look different

[This sub-discussion stemmed as one of the several replies to #Style vs. Usability. Note that you may find some references to other sub-discussions that have been closed and removed. -- Kynikos (talk) 04:32, 27 July 2013 (UTC)]

More about visibility: we could evaluate (which means I'm not supporting yet this idea, i.e. I'm brainstorming) the possibility of adding a little inline package icon at the end of Template:Pkg and Template:AUR in a similar fashion to what happens with regular external links, that get a little arrow. Thoughts?

I'm strongly against indentation as it won't work with installation requests that are included in longer sentences.

-- Kynikos 08:33, 19 January 2012 (EST)

If the icon for official packages is different from the one for aur packages, this may also let us avoid always adding "available in the official repositories" and "available in the AUR". -- Kynikos 11:46, 29 January 2012 (EST)

Well, if you find suitable icons. --AlexanderR 23:54, 29 January 2012 (EST)
Edit: and develop alternative presentation for text browsers --AlexanderR 23:54, 29 January 2012 (EST)
As an alternative to images, something like packageAURAUR could be used. -- Kynikos (talk) 02:43, 24 July 2013 (UTC)
We should also discuss, whether to change only AUR template, or also Pkg template. If we use packageAURAUR style, I think it would be OK to let Pkg as is, but it would not allow to avoid "available in the official repositories". Adding "official repositories" into superscript for Pkg template is not possible because it's too long, perhaps some abbreviation could be introduced for this purpose.
-- Lahwaacz (talk) 10:31, 24 July 2013 (UTC)
The wording "available in the official repositories" was practically required only for consistency with the "available in the AUR" wording, but a link to official repositories is already in pacman, and official repositories doesn't contain any useful information on how to install packages, as opposed to Arch User Repository. This is to say that we could leave Template:Pkg as it is, change Template:AUR to packageAURAUR and stop requiring the "available in *" wordings.
Note that just updating Template:AUR would make heaps of articles look weird, as they'd get two links to AUR very close to each other; a safer alternative could be:
  1. copy Template:AUR to Template:AUR_temp
  2. change all the current instances of Template:AUR to Template:AUR_temp using a bot
  3. update Template:AUR to the new style
  4. change all the instances of Template:AUR_temp back to Template:AUR manually, removing the "available in AUR" parts
(Template:AUR and Template:Aur are backlinked by almost 1500 pages though)
-- Kynikos (talk) 06:03, 27 July 2013 (UTC)
Other possibility could be to create separate templates for use in lists of applications, where the need to differentiate AUR and Pkg is obvious. I think it is not needed in article introductions etc., there are already phrases like "available in the official repositories" or "available in the AUR".
-- Lahwaacz (talk) 10:31, 24 July 2013 (UTC)
I like the other idea more, for simplicity, however this alternative can of course be taken into consideration. -- Kynikos (talk) 06:03, 27 July 2013 (UTC)

Daemons and modules


We need a more generic standard phrasing when requesting to "add daemons to the DAEMONS array..." (even avoid making reference to rc.conf, since Daemons links there already?) in the vein of what's been done with installation instructions, and point more clearly to Daemons. Similar problem with kernel modules and the MODULES array. Also the instructions for starting/stopping daemons and for adding/removing modules could be merged in the sentence.

I'd like to start a brainstorming session here to find the right wording example(s) to put in the guide. Of course objections to the whole idea are still taken into consideration.

We probably need a standard phrasing for immediate starting/stopping/loading/removing only, another standard for adding to DAEMONS/MODULES only and a third one for the cases where both immediate and automated action are recommended. I'll start with (I repeat, this is a brainstorming session):

  • "Start the foobar daemon."
  • "Load the foobar module."
  • "Add the foobar daemon to the DAEMONS array."
  • "Add the foobar module to the MODULES array."
  • "Start the foobar daemon and add it to the DAEMONS array."
  • "Load the foobar module and add it to the MODULES array."

Note that if we solve the problem of links color and font-weight as explained at the bottom of #Style vs. Usability, the links will always be blue/purple and bold, even in indented paragraphs. For now you can fake this effect by enclosing links in '''.

-- Kynikos 16:17, 31 January 2012 (EST)

  • I moved this part to the separate section as this discussion is not directly related to "formatting bloat" but rather to unification of phrasing.
  • Exact formatting depends on results of #Bold and italic discussion, so I propose to finish it before continuing this one.
>> objections to the whole idea are still taken into consideration
Well, I have already understood reasons for deprecating installation instructions and modules loading at startup/daemons autostart. All this is performed only once and there are a lot of troubles with giving command line snippets for this. But what's wrong with starting/stopping daemons? I'd better suggest to allow usage of snippets for this purpose but only for other reasons than creation of whole "Starting xxx manually" section, containing only that single line of code. IMHO, it is usually enough to mention existence and purpose of daemon in given package and providing link to Daemon. All daemons behave similarly, interaction with them in Arch is really simple; there is simply no need for adding same sections with same contents for every article. If writing snippet is really required to maintain workflow of step-by-step guide, then there is probably no need for restricting it (the same for loading/unloading) modules.
--AlexanderR 19:44, 31 January 2012 (EST)
Eheh with "whole idea" I meant the idea expressed in the first paragraph, since I was asking for possible methods of applying it without apparently leaving room for objections. I admit it wasn't clear at all :) So, just to give you an answer, it would look a bit inconsistent to me to allow daemon starting/stopping instructions and not installation instructions, also because we should resort to using snippets like:
You must now start the whatever daemon:
# rc.d start whatever
Which looks redundant to me, unless you wanted to suggest something like:
Now run:
# rc.d start whatever
Which I like even less because it's not teaching anything, it just leads the inexperienced user to copy-paste the command, without thinking of what he's doing.
If you had something different in mind, just give an example. -- Kynikos 18:20, 3 February 2012 (EST)
Again from PulseAudio:
Lets break workflow:
What looks better? --AlexanderR 00:37, 4 February 2012 (EST)
This argument seems rather circular. I fully support the last comment by Kynikos. And personally, I would combine the first two sentences in AlexanderR's second example to something like:
Since PulseAudio depends on the dbus daemon, start dbus and then start PulseAudio:
~ Filam 22:43, 4 February 2012 (EST)
Like this?
Looks nice, except usage of verb in link to daemon article: I agree with User:Vadmium about the fact that usage of such easter_egg links can a bit annoying and sometimes even misleading.
PS I am not going to challenge already reached agreement on deprecation of daemon instructions, so please consider adding something useful to #Quoting and underlining and #Bold and italic discussions, so that we can continue this one. --AlexanderR 00:40, 5 February 2012 (EST)

Daemon operations

I'd like to suggest you / we add wording & style suggestions for systemd daemon operations to Help:Style#Daemon_operations. --User:Stefanwilkens

Agreed, can you start with an example of suggestions? -- Kynikos (talk) 13:58, 3 October 2012 (UTC)
Considering that giving direct examples that can be copy pasted is deprecated, I would suggest something like this:
Use systemctl to enable <servicename> with <servicefile> during boot.
Note: Use systemctl to enable GDM with gdm.service during boot.
Or the more to the point:
<Action> <servicename> with <servicefile> using systemctl.
Note: Start GDM with gdm.service using systemctl.
Note: Enable GDM at boot time with gdm.service using systemctl.
Upon review of this, it seems that we may only have to adjust the references to rc.d and the old DAEMONS array from Help:Style#Daemon_operations and replace it with instructions fitting to systemd. For example:
Daemon operations
  • The standard phrasing is a simple list of the daemons involved, possibly remarking dependencies or conflicts with other daemons, and a link to Daemon.
  • If a required action is not covered in Daemon., it is acceptable to provide an example. Such an example should make use of the systemctl command and provide a listing of the service files involved.
  • The Beginners' Guide and its subpages are the only exceptions to the rules above.
Just suggestions to get the ball rolling, nothing is worse that outdated documentation. --stefanwilkens (talk) 18:25, 14 October 2012 (UTC)

Passing arguments to systemd units: give example commands or not?

About [4], [5] and [6]: the current version makes it look like there is a file dhcpcd@interface_name.service somewhere in the file system, the following sentence tries to explain that it is just an argument. IMO the original version was all clearer, more accurate and shorter, so I wonder if we can tolerate giving examples of how to manipulate systemd units taking arguments, excepting it from the current rule. -- Lahwaacz (talk) 08:29, 26 June 2014 (UTC)

Are [7] and [8] clearer? Perhaps it would be easier to add a paragraph to systemd#Using_units explaining arguments, rather than add an exception. After all, many .service files take arguments; on my install:
$ locate "@.service" | wc -l
--Alad (talk) 11:32, 26 June 2014 (UTC)
Oh well, the rule on daemons has certainly been one of the most controversial through time, it was originally designed for rc.d scripts [9] and after the switch to systemd it was only "translated", without doing any other adaptations.
systemd is certainly more powerful and we should start keeping that into account: I like Alad's idea, we should introduce unit instances (not "arguments") in systemd, also for educational purposes, without excepting the style rule. I would seriously consider adding brief systemd guidelines to Help:Reading (or maybe just a link to systemd). Finally we should add well-designed wording examples to Help:Style#Daemon operations (see discussions above), like we've done for installation instructions: in case of unit instances we should use the word "instance" (or whatever word we decide to use) to link to the newly created section in systemd.
-- Kynikos (talk) 06:18, 28 June 2014 (UTC)
I was quite surprised to find out that the description of instantiated units is missing in systemd (I guess Archers are fine with man page). I agree that there should be at least a short intro, something we can link to. This looks nice, we could put together something similar. And use more external links of course, unfortunately I can't access Lennart Poettering's blog, which as far as I remember described it quite well. -- Lahwaacz (talk) 08:59, 29 June 2014 (UTC)
Lennart's site seems to go down intermittently, right now it works again... --Alad (talk) 13:10, 29 June 2014 (UTC)
Marked Systemd#Using units for expansion. -- Kynikos (talk) 09:58, 30 June 2014 (UTC)

CSS updates

The style of <tt>, <code> and <pre> has recently been adjusted in the CSS to match that of code formatting templates.

I was wondering if now we should suggest using <pre> and space-initial lines instead of Template:bc in order to avoid having to add numbered parameters or <nowiki> tags when necessary. On the other hand, this may be seen as an incosistency since those hacks are still needed for its "sibling" templates ic, hc and keypress.

-- Kynikos (talk) 16:30, 4 May 2012 (UTC)

"Space-initial lines" are fine, but suggesting <pre> usage after so much effort put into getting rid of it does not look logical. --AlexanderR (talk)
I know this would be very radical, anyway just as an update I'm also mentioning that Template:Keypress doesn't exist anymore, and the advantage of not needing named/numbered parameters anymore would also apply to Template:ic if it was replaced by <code>, so my argument about inconsistency would apply only to Template:hc. -- Kynikos (talk) 04:17, 5 July 2014 (UTC)
Just a reminder: [10] Moving to the <pre> tags instead of Template:bc would effectively disable wiki formatting inside those blocks, and using space-initialized lines for large blocks is rather tedious. -- Lahwaacz (talk) 10:04, 5 July 2014 (UTC)
True, I forgot about that, it's enough to close this discussion. -- Kynikos (talk) 04:39, 6 July 2014 (UTC)

Better structuring

IMHO, many parts of article can be safely moved to descriptions of corresponding templates. For example, information about Template:Keypress actually belongs to template itself rather than this style guidelines. I believe, most people look at template page before using it. What do you think? --AlexanderR (talk)

Actually this idea would overlap with a larger project I've had in mind for some time now: merging editing and style guidelines consistently everywhere, and split them in several articles based on the various topics being dealt with. However I'd like to plan this carefully in advance, as it involves several pages, otherwise we risk increasing the mess instead of reducing it. -- Kynikos (talk) 10:04, 14 May 2012 (UTC)
> ..merging editing and style guidelines consistently everywhere, and split them in several articles based on the various topics being dealt with.
Sounds good. Note, that moving part of current content to templates can reduce overall size of all involved articles and possibly simplify further work. --AlexanderR (talk)
See also #Help:Talk. -- Kynikos (talk) 16:11, 25 December 2012 (UTC)

Related links

See also or Related in Article Summary?

I think we'd better be coherent whether to keep links, references etc. either in a "See also" section at the bottom of the article, or in one (or more) boxes under the Article Summary at the top right of the article.

See also #Article summary templates.

-- Kynikos 15:15, 21 September 2011 (EDT)

This is more a reminder than other, but I'm starting to like the idea of adding the rule to keep related ArchWiki articles in the Article Summary box only, and external links in See also sections only. Well, this way the "See also" default may even be changed (with bots, don't worry!) to a non-imperative, descriptive title like "Additional resources", "External links" or something like that. -- Kynikos 07:06, 14 December 2011 (EST)
Also remember that many external links in summaries can be found with Special:WhatLinksHere/Template:Article_summary_link. -- Kynikos 07:41, 24 January 2012 (EST)

Advantages of links in See also:

  • There is more space for link descriptions
  • It is likely one will read or skim the article before actively looking for additional reading material. This naturally leaves the reader at the end of the article. It is convenient for the reader in this case if links are at the end of the article. James Eder 00:29, 22 September 2011 (EDT)
  • It seems more common (elsewhere) to have links at the end of articles (when they are not inline with the rest of the text). Following common convention it may be better from a usability perspective. James Eder 00:29, 22 September 2011 (EDT)
    Especially for people used to Wikipedia, which uses the same wiki software. Vadmium 11:12, 26 October 2011 (EDT).
  • I am not sure how much we care about this but it having the links at the end could be more friendly to small form factor screens and screen readers. James Eder 00:29, 22 September 2011 (EDT)
  • As a section, "See also" gets its own TOC entry granting easy access from near the top of the article. Alternatively one may press the END key. James Eder 00:29, 22 September 2011 (EDT)
  • More formatting options here than in summary. Emiralle 13:12, 15 October 2011 (EDT)
  • More inclined to put external, or less closely related stuff here. Emiralle 13:12, 15 October 2011 (EDT)
  • See also section would not be skipped if you start reading the main text sequentially from the top. Vadmium.
  • [add more advantages...]

Advantages of links in Article Summary:

  • Immediately visible
  • Beyond some minor editing inconvenience, is there any real disadvantage of having the most interesting links in both locations? It could be advantageous for the reader to have some links in both locations. James Eder 00:29, 22 September 2011 (EDT)
  • I think putting very closely related links in the summary gives the topic more cohesion, and as James Eder said, they could be included at the bottom as well. Emiralle 13:12, 15 October 2011 (EDT)
  • It would theoretically be more effective in preventing duplication of content within the wiki, as (unexperienced) editors would have a clearer view of the articles where related content could already exist (true especially with series (or "rings") of articles on the same subject). -- Kynikos (talk) 02:46, 29 September 2013 (UTC)
  • [add more advantages...]


Inspired by [11], I was wondering if related links in "See also" sections or article summaries should be avoided if already present in the body of the article. I'd prefer having complete lists of related articles even if that implies duplicating some of them. -- Kynikos (talk) 11:09, 16 May 2012 (UTC)

> I'd prefer having complete lists of related articles even if that implies duplicating some of them
I'd prefer this way as well. Sadly listing all related articles may occupy most of vertical space, so there should be clear guidelines regarding choise of related links. And editors often don't have time to read even Help:Style... On the other hand, defining simple rule like "only links not present in text" can eliminate the very requirement for any additional rules. --AlexanderR (talk)
"only links not present in text" is too strict I think. Related links make some page more "visible" to readers. For example, I often click on them to learn more info about the same topic. But to be honest, I rarely click on the "in page links" even the links shown clearly in "See Also". They are much harder to be found and clicked. -- Fengchao (talk) 04:50, 19 May 2012 (UTC)


Inspired by [12], I was wondering if we needed a definition of what are the conditions under which an article can be considered related to another one. Honestly I can't think of something suitable at the moment, if somebody has good ideas, they're welcome here. -- Kynikos (talk) 11:09, 16 May 2012 (UTC)

Few ideas:
  • Alternatives to software, described in article
  • Methods and techniques alternative to ones described in article
  • Software <-> it's use case
  • software/technique <-> it's developer
--AlexanderR (talk)

Request to change recommended package installation style

I find the existing recommended package installation instructions to be unsightly because of excessive blue links (see Help:Style#Package_management_instructions), and I feel that my proposed examples significantly boost readability of articles. I propose changing the official recommendation to the following:

Install package from the official repositories.

or my lesser preferred:

Install package, available in the official repositories.

The three primary changes are:

  1. removing the link to pacman
  2. removing the link to Official Repositories
  3. changing "Official Repositories" to lowercase

I see no reason why a link to pacman and Official Repositories is necessary on every article. If an administrator of an Arch box does not know how to install packages or know what the official repos are, then god help them and any other users on that box because they are in for a poor experience. The Beginners' Guide makes it very clear how to install packages and that the user must be familiar with pacman and how pacman operates.

For the [multilib] example on Help:Style, I think it is important to continue mentioning that a package is in [multilib], and I still support linking to [multilib]. I propose the following for a [multilib] package:

Install package from the official [multilib] repository.

-- Jstjohn (talk) 20:02, 15 June 2012 (UTC)

As for the wording itself, "Install package from the official repositories" sounds indeed slightly better than the current one, so I think we can replace it. The same goes for the multilib example.
About the capitalization of "[Oo]fficial [Rr]epositories" I'm completely neutral, so unless somebody has opposing arguments I'm updating it, although using one or the other form is still equally acceptable.
The links are clearly the main topic of this discussion: actually none of them is explicitly mandatory yet, so, just as a start, I'd like to state that at least the link to the package is needed.
About the links to pacman and the official repositories, we could make them optional, but recommend to use them in pages that may be targeted to less experienced users (e.g. articles directly linked from the Beginners' Guide like Xorg and so on).
As always, it would be helpful to read somebody else's opinion ^^
-- Kynikos (talk) 10:04, 16 June 2012 (UTC)
I'd be fine with recommending that the links be used on pages linked from the Beginners' Guide, etc. I just find it bothersome seeing links to pacman on every wiki article. :)
And I fully support making Template:Pkg mandatory.
-- Jstjohn (talk) 02:02, 17 June 2012 (UTC)
We are indeed familiar with pacman so to most people who know how to use talk page, the pacman link is not needed. But we should remember lots of people can not remember all pacman installation instruction after reading Beginners' Guide. When Arch wiki change from pacman -S <package name> to current style, many users did get lost and asking what to do even when the link is provided. Remove installation link will make Arch learning curve steeper.
-- Fengchao (talk) 11:03, 18 June 2012 (UTC)
I understand your concern, but I honestly don't know how Arch users cannot remember such a simple and often used procedure. Users should know to reference the Beginners' Guide or the pacman wiki articles if they forget basic pacman operations. To mitigate this unfortunate situation, I'm strongly leaning towards making some redirects to the pacman article. Notably install and install package, which I expect would be the most frequently used search terms if someone doesn't know how to install a package.
If we can create some good redirects for common searches like that, would your concerns be addressed (or at least partly)?
-- Jstjohn (talk) 23:03, 18 June 2012 (UTC)
Adding redirects is a good idea. Add all Arch users indeed remember it because who can not remember them before finishing reading Beginners' Guide will turn to other distro. :) I am not objecting here. However I did remember when change away from # pacman -S command line, many people object and complain. Had you read #Style vs. Usability above yet? We had a hard time to find a balance between different concerns for this style. Change it will stir things up again.
-- Fengchao (talk) 09:30, 19 June 2012 (UTC)
Ok, I've reworded the section, but I've decided we can't really get rid of links to pacman: installation instructions have been a very controversial style topic, and the current solution is some kind of a compromise to which I think we should adapt for the sake of consistency.
About those redirects, creating them can be helpful, even though there's a little (I guess negligible) chance that somebody following them is instead looking for an article on how to install Arch and not a single package.
-- Kynikos (talk) 10:48, 21 June 2012 (UTC)
Do we have the ability to make disambiguation pages, similar to Wikipedia, that we can use for the install redirect?
I'm going to create a redirect for install package and install packages now.
-- Jstjohn (talk) 13:58, 21 June 2012 (UTC)
Another complaint I have regarding the current package installation instructions is how much typing must be done simply to state "Install blah from the blah". It would be much easier/better, for several reasons, to create a package installation template which does this for us. I imagine it would function quite similarly to Template:Pkg except that it would put all of the verbiage around the package link. So, for example, using {{PkgInst|xmonad}} would produce the following auto-magically:
Install the package xmonad from the official repositories.
I don't have much preference for this proposed template's name. I initially kept the name short (e.g. {{Pi|xmonad}}), but I didn't want people to confuse that with pi. I went with {{PkgInst}} in my example because it is clearly different from Template:Pkg, but the similarity to/inspiration from Template:Pkg is hopefully obvious.
Because this only deals with official packages, it should be appropriate to create one for AUR packages as well. I propose that {{AURInst|opennebula}} would produce the following:
Install the package opennebulaAUR from the AUR.
-- Jstjohn (talk) 14:52, 21 June 2012 (UTC)
Let's leave Install uncreated for the moment: somebody may use it in installation instructions (Install package ...) and it would be confusing if it pointed to a disambiguation page.
About the installation template, it has been proposed already in the past, and just like other similar ideas (adding daemons to DAEMONS etc.) it has been discarded because it could be applied only in a subset of the cases that require the installation of packages: you couldn't use it when there's more than one package to install, you couldn't use it when the installation request has to be integrated in a longer, more complex sentence. Besides, writing an installation sentence is not something you have to do several times a day, and in any case it takes about 10 seconds to write it each time, I don't think it would give a noticeable advantage. Last thing - but this is just a personal feeling - it would give me a sense of unnecessary complication, not in the Arch Way :)
This discussion is open, however, more ideas are welcome.
-- Kynikos (talk) 11:59, 24 June 2012 (UTC)
This discussion has produced an improvement in Help:Style#Package_management_instructions. The proposal of a template is discarded, see my post above. The discussion is now closed. -- Kynikos (talk) 04:44, 5 July 2014 (UTC)



As discovered in Talk:Common Applications#Improving the title, the rule regarding title case is currently unclear (and absent from this style guide). Help:Editing#Creating pages states Titles should be capitalized appropriately: Title for New Page; not Title for new page.

I propose the following style rule to be added under Help:Style#Title (as the first point):

  • Titles should be capitalized using title case, as in "How to Install Arch Linux on a Toaster."

Any objections or suggestions before I add this? Do you think it is necessary to contrast with the rule for headings (which should use sentence case)?

-- pointone 16:37, 19 January 2012 (EST)

Of course we need a rule for title case. Referring to "Title Case" should work in the majority of cases, however I'd use "How to Easily Install Arch Linux on a Blue Toaster" or something like that as an example, just to include an adverb and an adjective (assuming I've capitalized them correctly).
Then we should probably also mention the correct way to capitalize the application names that are officially written in lower case, and this would probably need a reference to Template:Lowercase title, which by the way I wanted to mention at the first position in Help:Style#Layout, together with some behavior switches.
I don't think it's necessary to explicitly contrast this rule with that for section headings.
-- Kynikos 07:16, 20 January 2012 (EST)
This topic has been touched on also in Talk:Article Naming Guidelines#Article title capitalization, mentioning Wikipedia's policy which seems to conflict with the "title case" idea. -- Kynikos (talk) 11:49, 5 July 2012 (UTC)
I'd like to reopen this discussion because I think it really needs some clear rule. I find current state really confusing - we have Power Management, but Power saving; Kernel Mode Setting, but Kernel modules etc. The same applies for categories too: Category:Hardware Compatibility List, but Category:Hardware detection and troubleshooting. As a result, I always have to check all interwiki links I want to use - sometimes there are redirects from sentence case to title case (or vice versa), but sometimes there are not.
I prefer sentence case, it's simpler and Help:Article naming guidelines uses it in most examples. On the other hand, I think title case is currently more widespread (but I have no statistics).
-- Lahwaacz (talk) 16:54, 7 August 2013 (UTC)
This discussion has never made it to become a rule because I do happen to prefer Sentence case to Title Case too, especially for coherence with Wikipedia, but also because it looks tidier to my eyes. The huge problem here is, as you've noticed, that title case is much more widespread, and simply moving the wrong-cased articles would create heaps of useless redirects, not talking about categories, whose members should all be edited, since redirects don't work for categories. Moral of the story, I have keep this one on hold for a while longer, sorry...
-- Kynikos (talk) 11:53, 8 September 2013 (UTC)
Of course the current rule in Help:Editing#Creating pages (use Title Case) is what regulates the matter for the moment. -- Kynikos (talk) 11:56, 8 September 2013 (UTC)
Because the current rule is only stated on Help:Editing, can I/we at least move this rule to Help:Article naming guidelines? It doesn't make much sense for the rule to be on Help:Editing but not on Help:Article naming guidelines.
Also, I recently requested an article rename to comply with this rule[13]. Because there is still some ongoing discussion about this, should I revert this change?
-- Jstjohn (talk) 04:15, 6 February 2014 (UTC)
Moving the rule to Help:Article naming guidelines would be a good idea, but do we want to finally settle this matter? I've opened a poll below: if sentence case wins, re-categorizing the articles will be relatively easy to do with a bot, and anyway it won't be an urgent task. -- Kynikos (talk) 16:05, 7 February 2014 (UTC)
Just to make it clear, "sentence case" is as defined in wikipedia:Letter case#Usage, plus common words that are part of a proper name or an upper-case acronym must be capitalized, e.g. "Advanced Linux Sound Architecture", not "Advanced Linux sound architecture". -- Kynikos (talk) 02:00, 8 February 2014 (UTC)
If sentence case wins, I'd except The Arch Way explicitly in the rule.
Then I'd like to ask your opinions on Main Page: would you except it as well or move it to Main page? It's "Main Page" by default, but I wouldn't mind moving it for consistency, also because it's spelt lower-case in the left navigation panel (due to MediaWiki:Mainpage-description). Also note that some system messages should be updated accordingly, like MediaWiki:Mainpage.
-- Kynikos (talk) 05:52, 8 February 2014 (UTC)
I completely agree that The Arch Way should remain in title case because it is a proper noun. I also think a decent argument could be made that Main Page is also a proper noun because there is only one "main page"; so it would be similar to calling it "The Main Page". As for the left navigation panel, I think we should make it consistent throughout that section, so everything is sentence case. I don't feel too strongly either way about Main Page vs. Main page, so if you want to go with Main page to make it consistent with the left navigation panel, I won't put up any fight.
-- Jstjohn (talk) 02:31, 9 February 2014 (UTC)
Eheh we can't justify exceptions with the fact that those titles are proper nouns of their articles, because that would be self-referential and true for every article ^^'
"Main Page" is only the name of that article, not of something else, so theoretically it shouldn't be capitalized, and that's why leaving it like that would be an exception to the rule. Now, just like with every change, it will feel a bit weird at the beginning to see the titles of some articles (like Main Page) with a different capitalization from the one we were used to seeing, however it won't be long before we get used to the new capitalization ;) (And excuse me if I'm talking like sentence case had already won, but looking at the votes it does seem pretty popular... :P )
-- Kynikos (talk) 04:57, 9 February 2014 (UTC)
Ah, and it's not necessary to mention The Arch Way as an exception: I've just created The Arch way as a redirect, and that'll be enough. -- Kynikos (talk) 05:06, 9 February 2014 (UTC)
The redirect will not be enough for an exception until the transition is complete, there are other "wrong" redirects - e.g. Maximizing performance. The transition to the new scheme will take a while, so any exceptions should be made explicitly in the rule.
And of course I agree that The Arch Way should remain in title case. If having Main page instead of Main Page will not cause any technical problems, then I think there is no reason to justify an exception.
-- Lahwaacz (talk) 20:43, 11 February 2014 (UTC)
Well, a redirect is enough to prevent users from moving a page to such title, as the redirect should be deleted first. Of course it wouldn't prevent them from copying there the contents of such article, but that's a very bad practice in general in the first place, and watching The Arch Way wouldn't be so hard (I expect only a few (well-known) users will be active in the renaming, and they'll all be aware of this discussion and the exceptions).
The reason I don't want to mention The Arch Way as an exception is that I consider it only a half exception, i.e. for me "The Arch Way" is the proper name of Arch's philosophy, so IMO it's more about reminding that, than excepting it, and a discussion like this is the proper place to do it.
About "wrong" redirects, admin intervention is required in any case, as they'll have to delete the redirect first, to make way for the move.
Having Main page shouldn't cause technical problems because its name is regulated by so-called system messages (the MediaWiki namespace), and fortunately grep -r Main . in the archweb repository doesn't return links to the Main Page article, as all generic links to the wiki are made through links.
-- Kynikos (talk) 06:42, 12 February 2014 (UTC)
The users will not be able to do anything to The Arch Way since it is protected (they can't even move it)...
Completely agree with your second point though. I imagine this discussion will be open during the process with some guidelines, so it will be a reminder during the process, and the redirect will be a reminder after this discussion is closed/deleted. No further action required, just wanted to make it clear.
-- Lahwaacz (talk) 08:19, 12 February 2014 (UTC)
Lol, didn't think it's protected ^^' Some initial guidelines are outlined below. -- Kynikos (talk) 08:09, 13 February 2014 (UTC)
Closed, the rule has been enforced for a long time now. -- Kynikos (talk) 05:05, 5 July 2014 (UTC)

Renaming guidelines

I'm closing the poll because the results are very clear: now it's a matter of A) changing our rules and B) renaming the wrong-named articles.

Of course updating the backlinks of the renamed articles is not necessary, but still welcome, especially in the most important cases.

To all Admins and Maintainers: do not move the articles without leaving redirects, as we risk breaking external links for no real advantage (redirects don't pollute anything).

To all Admins: if the correct name is currently a redirect that points to the Title-Case'd name, the correct procedure is to first delete the redirect and then move the article, not copy the content into the redirect page (which wouldn't preserve the history of the page).

I strongly discourage renaming categories manually, as doing it with a bot is 100x faster, so please use your precious wiki time for tasks that require a human brain.

-- Kynikos (talk) 07:00, 12 February 2014 (UTC)

...And note that moving pages is likely to create double redirects: it's quick and easy to fix them with a bot (e.g. Wiki Monkey), however if you want to do it manually, at least please fix the double redirects that are more likely to be visited by unaware users.

I'll try to fix double redirects frequently with Wiki Monkey, of course any other user of that bot is invited to help (it's just a matter of clcking on the dedicated button found in Special:SpecialPages).

-- Kynikos (talk) 11:32, 13 February 2014 (UTC)

Additional tip: updating backlinks is another thing that is easy to do with a bot: use a regex substitution on the WhatLinksHere page of the renamed article and change (\[\[|\{\{Related\|)My[ _]Article(\]\]|\}\}) to $1My article$2. Note that it could be too dangerous to do more complex replacements: after doing that one, only a few backlinks should be left, if any at all, and it should be safer to fix those ones manually. -- Kynikos (talk) 00:32, 15 February 2014 (UTC)

Thanks - I've modified it to (\[\[|\{\{Related\|)My[ _]Article(\]\]|\}\}|#) to match even links to subsections. -- Lahwaacz (talk) 08:16, 15 February 2014 (UTC)
Another tip would be to update only the Main namespace - as you said, the redirects don't pollute anything, talk pages can happily stay with the old links... -- Lahwaacz (talk) 15:07, 15 February 2014 (UTC)
Definitely, although also e.g. the Help and ArchWiki namespaces should better be updated: you can use a filter for that: !/^(User|Talk|[a-z]+ talk):/i. Plus the replace regex can be further improved to (\[\[|\{\{Related2?\|)[ _]*My[ _]Article[ _]*(#|\||\]\]|\}\}) to also include Related2 templates and links with alternative text. -- Kynikos (talk) 11:27, 16 February 2014 (UTC)
Sorry, please do not use wiki Monkey <= 1.14.3 for fixing double redirects because it removes link fragments. Still, don't do it manually either, I will solve all the double redirects using a fixed development version of the bot meanwhile. -- Kynikos (talk) 14:02, 18 February 2014 (UTC)
Right, fixed and released, happy double redirect fixing! :) (Sorry again) -- Kynikos (talk) 15:16, 18 February 2014 (UTC)
Closed, these guidelines apply to any kind of renaming, and the bot parameters have been copied to and, which appear to be the only ones involved in the change. (I'm trying to slim down this talk page a bit...) -- Kynikos (talk) 05:05, 5 July 2014 (UTC)

Admin intervention required

Here is a list of pages that require admin intervention (the sentence-cased title redirects to the title-cased title). Just strike what is finished, other pages may follow... -- Lahwaacz (talk) 08:53, 23 February 2014 (UTC)

Closed, please use User talk:Kynikos or ArchWiki talk:Administrators for more reports. -- Kynikos (talk) 05:05, 5 July 2014 (UTC)

Poll (closed)

"Title Case" or "Sentence case" for titles? Read the discussion above and vote below.

Title Case
no votes
Sentence case
Kynikos (talk) 16:05, 7 February 2014 (UTC)
Lonaowna (talk) 20:10, 7 February 2014 (UTC)
Jstjohn (talk) 00:17, 8 February 2014 (UTC) (under the, perhaps obvious, condition that proper nouns and acronyms retain their capital letters)
Karol (talk) 03:11, 8 February 2014 (UTC)
Lahwaacz (talk) 20:34, 11 February 2014 (UTC)


Sentence Case wins. -- Kynikos (talk) 07:00, 12 February 2014 (UTC)

Application name capitalization

Which are the rules of capitalization of certain names? For LibreOffice there is no doubt, but for example is it 'bash' or 'Bash'? Probably the documented one is the preferable, so 'bash', 'Bash' when starts a sentence, aria2c everywhere. For zsh neither man pages are coherent. -- Flu (talk) 18:00, 19 May 2013 (UTC)

This topic is rather interesting: it's quite natural that we should follow the capitalization used in the upstream documentation, and this guide should probably mention it. I'd also like to remark whether the name should be always capitalized at the beginning of a sentence or not: honestly my position would be to still follow what the upstream documentation does.
In case the documentation is not coherent, I guess there's nothing we can suggest, except for being consistent throughout the article, _and_, if the application is mentioned in other articles, capitalization should be consistently based on the main article for that application (e.g. Bash).
Note that Bash is always capitalized in
-- Kynikos (talk) 15:00, 22 May 2013 (UTC)
so Bash is written wrong in Help:Style#Shells, (lol, forgive me :) ) -- Flu (talk) 10:29, 3 June 2013 (UTC)
Ahah perfection is unreachable, you will always find something to report... Anyway in this case "bash" _would_be_ written "wrong" in Help:Style#Shells only if the above had already been enforced as a rule ;) (but I'll forgive you for this blunder, don't worry :P ) -- Kynikos (talk) 12:32, 3 June 2013 (UTC)
I like the way the Git project uses both "Git" and "git" in their documentation based on what the author is referring to. They use "Git" when talking about the project/software generally, and they use "git" when referring to the compiled program used when running commands [14]. This style makes it quite easy to know whether to use "Bash" or "bash", etc.
-- Jstjohn (talk) 02:42, 11 January 2014 (UTC)
That is certainly logical, with Help:Style/Formatting_and_Punctuation applied it would be "Git" (plain text, first letter uppercase) and "git" (italic, all lowercase). I believe that with proper context it would not be confusing, but for the controversial cases it's probably best to place a note with some explanation into the talk page, as it has been done for Btrfs: [15]. -- Lahwaacz (talk) 16:09, 31 January 2014 (UTC)
In my view Git makes its spelling convention look more complicated than it is: IMHO it just says "always use 'Git', except when talking about the executable, which is a lower-case filename and couldn't be run otherwise". Anyway we could indeed enforce such a convention, but only for applications that A) don't have an official or common capitalization convention and B) are commonly run through an executable that has the same name as the application itself. This would of course settle Bash and Btrfs cases though. -- Kynikos (talk) 04:50, 1 February 2014 (UTC)

List of Applications and See also

  1. I suggest for lists like List_of_Applications/Multimedia to use capital letter for the first letter of the description, NO dots at the end (this behaviour seems to be preminent in Wikipedia) and to avoid totally articles ('A ..' is annoying). Is it ok?
  2. In the same list it may be fair to put {{Grp|group}} beside items that have their one.
  3. The See also section should be treated as above lists.

-- Flu (talk) 18:00, 19 May 2013 (UTC)

I support 1. and 2. except for the dots at the end of descriptions, which I would require instead, since sometimes the App template has long descriptions, even made of several sentences, and including all the puntuation only omitting the final dot would look weird to me.
About 3. I don't understand what you mean, can you be more specific?
However I'm also wondering if these rules should be hosted here (if they refer to the use of Template:App) or in Talk:List of Applications (if they refer only to List of Applications and subpages).
-- Kynikos (talk) 12:23, 26 May 2013 (UTC)
About 3: I just mean that a section like Aria2#See_also must have capitalized letters and no dots (or whatever the standard would be).
About the hosting place: page like CD_Burning#Burning_CDs_with_a_GUI or Conky#AUR_packages are not directly related to List of Applications, so I think it is worth to host a rule here. Plus this rule would apply also to any other list, like E4rat#Process --Flu (talk) 16:53, 26 May 2013 (UTC)
Still about 3: I see, usually See-also links have much shorter descriptions, in that case I would apply a no-dot policy. Still open to more opinions though.
Hosting place: a rule about lists of applications would probably best fit in Template:App, also in light of my plans to decentralize style rules in general. A rule about See also sections would instead fit this guide indeed, at least for the moment.
-- Kynikos (talk) 13:17, 28 May 2013 (UTC)

One link to the package in a paragraph is enough

Do we need multiple links to the same package, wiki article etc. in the same paragraph? I understand that if the article is very long, the links may be used in different sections, but isn't "In the past, Arch used SysVinit as the init process. Now on new installs, Systemd is used by default. Existing SysVinit users are recommended to switch to systemd." with 2 links to SysVinit and 2 links to systemd a bit too much? -- Karol (talk) 23:15, 21 May 2013 (UTC)

First thing, probably in the title you mean links to articles in general, not only packages, right?
However, I definitely agree, I guess we could extend the rule to the same section or even the whole article, but I'd like to exclude some cases, like "See also" sections (see #Lists of related links), and to make the rule compatible with Help:Style#Official packages and similar.
-- Kynikos (talk) 15:11, 22 May 2013 (UTC)
Just a reminder: this is affected by Help:Style/Formatting_and_Punctuation#First_instances, not sure if it sould be mentioned directly on Help:Style. -- Lahwaacz (talk) 16:35, 1 September 2013 (UTC)

Red links

Is creating links to nonexistent wiki articles a good thing because it encourages creation of wanted pages? Is this OK or a bit too red? One discussion asserted that it's OK to create red links when using the app template, but I don't like them and I'd prefer not to litter articles with references to non-existent articles. -- Karol (talk) 13:12, 24 May 2013 (UTC)

I remember reading something like "Only add links to nonexisting wiki articles when you intend to add it soon". Forget where did I read it, but I agree with it. -- Fengchao (talk) 04:59, 25 May 2013 (UTC)
Fengchao's unknown quote doesn't sound bad to me either. This wasn't the central topic in Template talk:App#Introducing default argument by the way (that discussion is still valid, though). -- Kynikos (talk) 14:39, 2 June 2013 (UTC)
I removed the red links that were in English articles. Closing. -- Karol (talk) 22:03, 12 July 2013 (UTC)
Reopening, I will add "Only add links to nonexisting wiki articles when you intend to add it soon" somewhere. -- Kynikos (talk) 03:16, 13 July 2013 (UTC)

Laptops format

There are many pages concerning laptops and other hardware (Gamecube, Raspberry Pi), but there is no common formatting rules. Is there a best way to set up a hardware page? Flu (talk) 16:04, 26 May 2013 (UTC)

Most of the are out of date or going to be out of date. So I think the rule should be link to related Arch Wiki page instead of duplicating info. If we apply this rule to Hardware pages, most of them should be empty. -- Fengchao
To answer Flu's question, no, we don't have any templates for hardware pages (yet?).
The rule mentioned by Fengchao is already in the guide: Help:Style#Hypertext metaphor.
-- Kynikos (talk) 14:46, 2 June 2013 (UTC)

Prefer linking to the article than to the package

When mentioning an application, prefer linking to its article, if existing, rather than directly to the package. -- Kynikos (talk) 13:24, 28 May 2013 (UTC)

+1, apart from the standard "Download foo from the official repos" and similar. -- Karol (talk) 13:27, 28 May 2013 (UTC)

git/vcs/source builds

In some article there are source build instruction like Jumanji#Method_2:_From_Source and [16] or AUR git references like [17]. I think they are pointless because:

  • of course you can build application on your own, there is no need to say that.
  • there is plenty of git/patched/vcs variants in AUR. One can decide to install them by their choice.

What about a rule to forbid git/source references unless they are the only chance?

(oh no, another time) -- Flu (talk) 21:15, 2 June 2013 (UTC)
IMHO 'make && make install' instructions should go.
I have nothing against describing different AUR packages, whether VCS or not. PKGBUILDs are sometimes pretty complex and it's not obvious what's the difference between the various AUR versions of a package - if any.
Please sign your talk page edits Help:Discussion#Join_a_discussion. -- Karol (talk) 20:21, 2 June 2013 (UTC)
Yes, manual compilation instructions can be removed, but only when an AUR package is available. A rule may be added for this.
No, please don't remove links to "alternative" versions of packages in AUR; treat every AUR package as the others, there are not AUR packages more "official" than others: if they all install the same application, they _can_ (i.e. not _must_) be mentioned in the same article.
-- Kynikos (talk) 05:05, 3 June 2013 (UTC)
Just mentioning a recent related example, [18], that I consider perfectly reasonable. -- Kynikos (talk) 08:10, 12 June 2013 (UTC)

Ellipses in code examples

Reminder: mention ellipsis as an allowed form of extraneous code in examples; Help:Style#Command line text is already forbidding comments next to commands and we're going to add formatting style rules for "pseudo-variables". -- Kynikos (talk) 03:21, 13 July 2013 (UTC)

Talk pages of redirects

[moved from User talk:Kynikos#Talk pages of redirects -- Kynikos (talk) 10:01, 22 August 2013 (UTC)]

I didn't find any rule/official policy regarding talk pages of redirects, but you made me think about it.[19] Should they be deleted (of course with the exception of actual issue regarding the redirect)? What would that mean for users (non-admins) - should the talk page be marked for deletion? Or explicitly ask some admin to delete it? Or should the talk page be just blanked (assuming all issues were solved before the redirect)? I ask because now I realized that I left quite a mess behind me when I redirected some pages. Anyway, I think that some specific instructions to either Help:Style#Redirect pages or Help:Editing#Redirects won't hurt. -- Lahwaacz (talk) 11:41, 21 August 2013 (UTC)

It's true, there's no written policy on this matter. Blanking a page is not an option in any case. If the redirect target's talk page doesn't exist, the redirect's talk page should be moved there (thus preserving its history); if the redirect target's talk page already exists, any redirect's talk page discussions should be merged there. The redirect's talk page can then be either redirected to the target's talk page (automatic when moving), fixing any double redirects, or marked for deletion (without redirecting), fixing any backlinks first. Do we want to enforce only one of these possibilities or leave the choice case by case?
Note that admins and maintainers have the ability to move a page without leaving a redirect (deleting the original title), which could be taken into consideration, of course still taking care of fixing any backlinks first.
Finally, this could be part of an old idea of mine to create a page with checklists/procedures for the most common operations on articles, but that would be another discussion :)
-- Kynikos (talk) 10:19, 22 August 2013 (UTC)
Sorry for the delay, I've been inactive for a while.
Clearly discussions that become irrelevant after the redirect (like Talk:Tint#Merge with Tint2) can be removed. There may be discussions that are still relevant after the redirect (e.g. content related issues, can't find any good example right now), these issues should preferably be solved before redirecting the page, but that's up to the editor. I agree that remaining discussions should be moved/merged to the talk page of redirect target, so the question is what to do with the blank talk page?
I understand that there may be external websites with links to talk pages on ArchWiki and deleting the old talk page instead of redirecting it is rather unfriendly. On the other hand, those links are not used very often, especially for talk pages of some outdated, unmaintained or not very important pages. Just deleting it is much simpler (eh, the redirect is simple consequence of moving the whole talk page, but when the target talk page exists, deleting the source is simpler).
I also think that the redirects (at least for talk pages) should be deleted after some time, just another cleanup step. Especially if the main page was redirected for the second time (e.g. to fix some double redirect), take Talk:Suspend to Disk as an example.
Generally I don't have anything against redirects, it just makes the maintenance more difficult. For talk pages I think they are mostly superfluous.
-- Lahwaacz (talk) 19:11, 26 August 2013 (UTC)
One problem I see is that deleting a redirecting talk page will make the history of any merged discussions inaccessible to normal users. Anyway this could be trivial, and recommending to mark the talk page for deletion would leave the final choice to an admin, who is supposed to be able to judge what's best to do, also considering redirecting as a possibility. So I've added a procedure to Help:Editing, do you like it? -- Kynikos (talk) 13:04, 28 August 2013 (UTC)
Looks good. An idea: Help:Editing#Redirects could be split into three subsections, 1) what is a redirect, 2) when to redirect a page, 3) how to redirect a page. This could be applicable also to other procedures from your ideas and probably deserves separate discussion. -- Lahwaacz (talk) 14:52, 28 August 2013 (UTC)
As I said earlier, I messed up a few talk pages when redirecting. I've now marked most of them for deletion, see User:Lahwaacz#Messed_up_by_redirecting_the_main_page for quick list. The last one in the list, Talk:Map Custom Device Entries with udev, contains two open discussions - I doubt they are still relevant, but I'll have to investigate further. -- Lahwaacz (talk) 15:47, 28 August 2013 (UTC)

Distinguish fragment identifier interwiki links?

Similarly to #Visited_links_color, can we distinguish fragment identifier interwiki links (those written as [[#foo]]) from other interwiki links (generally pointing to some other page)? I find something like [[#PolicyKit authorization|PolicyKit authorization]] [20] kind of confusing, it should be clear that the link points to a section on current page and not to separate page. Possibilities:

  1. prefer [[#foo]] instead of [[#foo|foo]] - this does not solve something like [[#Run daemon|run the daemon]], also note that the fragment is case-sensitive
  2. add some icon (superscript?) in front of/behind the link, I was thinking about the arrow shown in history pages (but without the link to the section)
  3. use some other color

I'd vote for the second, it seems to be the most universal. Or does anybody have some other suggestion?

(Looking at the second link in this post, something similar could be done for links to Wikipedia. In this case, I propose adding superscript W behind the link.)

Sorry if this has already been discussed somewhere else, I don't have the time to search it right now.

-- Lahwaacz (talk) 19:41, 7 October 2013 (UTC)

Talking of distinguishing links, external https links are not distinguished either:
Perhaps a bug?
-- Lahwaacz (talk) 06:10, 10 October 2013 (UTC)
About the little icons next to links, I guess we could do it easily with CSS attribute selectors in the skin files.
About the https icon in particular, it looks it was disabled on purpose for some reason: [21] (line 67) I'd be curious to know why.
Of course to implement all this, a bug report should be opened and very likely patches should be prepared, so if you think you have the time to work on it, the project is at [22] with links to clone the repo. I'd be interested in giving a hand of course :)
-- Kynikos (talk) 09:53, 10 October 2013 (UTC)
Thanks for pointing me to the right direction, here's the commit about the https links: [23].
Let's see if I can get to this again this weekend...
-- Lahwaacz (talk) 15:05, 10 October 2013 (UTC)
I sent an email to Pierre about the commit in November and did not receive any reply, so I submitted a bug report: FS#38769 - hopefully it won't be missed. -- Lahwaacz (talk) 16:00, 2 February 2014 (UTC)
We'll see, I've submitted a patch, but unfortunately wiki bugs, even if easy to fix, have a long life... -- Kynikos (talk) 10:17, 3 February 2014 (UTC)

Problem with keyboard keys style

I could use some help with Keyboard Shortcuts:

According to Help:Style#Keyboard_keys, Ctrl+Alt++ should be Ctrl+Alt++, but is that clear enough? (see Keyboard_Shortcuts#X11)

Also, what would be the preferred style for showing multiple shortcuts for some modifier combination?:

  • Alt+.or_
  • Ctrl+Alt++/-
  • Ctrl+Alt+F1, F2, F3, ...

(note: someone used ⇑ Shift on that page, the arrow looks really funny :D )

Edit: the Ctrl+Alt++ shortcut was either dropped from X or is specific to NVIDIA, so I've removed it from the list of standard shortcuts. The only references I found were about 6 years old, the original is probably this.

-- Lahwaacz (talk) 22:22, 16 December 2013 (UTC)

(I don't wanna know where you've downloaded the font you're using with your browser... XD )
Oh well, even though Ctrl+Alt++ was (luckily?) outdated in that context, that's certainly a big flaw in the style rule... What do we want to do, switch to the Ctrl+Alt++ format? It would invalidate many of the style edits that have been done in the last months, but a bug is a bug ^^ Any better ideas?
About variable combinations, maybe we can just give some examples but leave the choice up to the editor?
-- Kynikos (talk) 13:48, 17 December 2013 (UTC)
I would not change the rule for just one shortcut (resp. two: Ctrl+Alt+-), converting it back would be really exhausting. If another instance appears, I'd create an exception for it. Or, even better, just link to an external documentation :P
Regarding the second problem I agree with leaving it up to the editor. Examples could be:
  • press Alt+. or Alt+_
  • press Ctrl+Alt+FN to switch to the N-th virtual console
i.e. basically use the full, expanded form or the pseudo-variables.
-- Lahwaacz (talk) 22:12, 18 December 2013 (UTC)
Well, let's just suspend this discussion until a similar problem is found again then, if ever. I'll think about closing it next time I'll come here to do some general clean up. -- Kynikos (talk) 10:25, 19 December 2013 (UTC)
Putting spaces around the + character would mitigate some of the confusion in the example Lahwaacz pointed out, but this would unfortunately require a lot of work to bring everything up to a new standard.
-- Jstjohn (talk) 02:32, 11 January 2014 (UTC)
Um... Ctrl + + doesn't look much clearer than Ctrl++ to me, if one day we'll need to change the rule for keys, we'll better do it the safest way, which probably is Ctrl++, since as you point out it's going to be "a lot of work" in any case. -- Kynikos (talk) 08:51, 12 January 2014 (UTC)

Grammar errors throughout Help:Style

I've found a large amount of grammar errors throughout Help:Style, and it would be quite tedious to list a before and after for each one here in order to get them fixed. Would it be possible to either temporarily unlock Help:Style for editing (and closely monitor it for unauthorized changes), or if you don't want to unlock it for editing, should I just provide a pastebin with the revised wiki markup that you can copy/paste into the locked page? The downside to the latter option is that one really large change can be a pain to sort through in the history due to the lack of more verbose comments; although, if it's mostly simple grammar fixes, I guess this wouldn't be too big of a problem, as the change comments would likely be quite minimal.

-- Jstjohn (talk) 03:41, 11 January 2014 (UTC)

It would be awesome if you could fix those errors, it will also be a good chance for me to improve my English: the article is unlocked now. Just make sure not to alter the explicit and implicit meaning of rules, e.g. [24] ;) -- Kynikos (talk) 05:16, 12 January 2014 (UTC)
I have a general question: what are the rules for using mdash ("—") vs. ndash ("–") in English literature? Is there supposed to be a space around them or not?
(I did not intend to challenge your work, I'm just curious - the rule is very likely to be different from those used in Czech...)
-- Lahwaacz (talk) 20:57, 11 February 2014 (UTC)
There is not supposed to be a full space around the em dash ("—") or the en dash ("–"). Ideally, the em and en dashes will be surrounded with a hair space, which is just wide enough to put a one pixel space between the dash and the adjacent characters, which makes it easier to read because the dash doesn't look like it's part of an adjacent character. I did not put hair spaces in my edits because I generally find it tedious to do.
As for when you should use the em dash vs. the en dash... the em dash is used for large pauses in speech or for side notes — notice the hair spaces around these em dashes — and the en dash is used for numeric ranges (e.g. 47 – 83).
The hyphen looks similar to the en dash ( - –  ← hyphen on the left, en dash on the right), but the hyphen is only supposed to be used between certain compound adjectives and nouns.
There's also the minus sign ("−"), which looks very much like an en dash ( − –  ← minus sign on the left, en dash on the right). It should only be used in mathematical formulas or when writing negative values (e.g. 47 − 83 = −36)
If you haven't noticed, I'm a bit of a typography geek. haha
-- Jstjohn (talk) 02:02, 13 February 2014 (UTC)
Thanks for this nice explanation! It is a shame that the wiki markup language does not have special syntax for this punctuation, entering the HTML codes is really PITA. There are some packages for LaTeX that translate "--" into en dash and "---" into em dash. But typographically, TeX is on completely different level than wiki. -- Lahwaacz (talk) 08:08, 13 February 2014 (UTC)
We could possibly add MediaWiki templates for the em dash and en dash. Adding a template for the minus sign seems like it might be overkill. For example, {{emdash}} or {{em dash}} would output &.#8202;&.mdash;&.#8202; (without the dots, of course)
-- Jstjohn (talk) 23:59, 18 February 2014 (UTC)
I say let's keep it simple, who would use those templates in practice? They would also go against our decision to e.g. use typewriter quotes instead of typographic, see Help:Style/Formatting_and_Punctuation#Quote_marks. As Lahwaacz mentioned, a wiki is not TeX, it's designed to keep source and rendered text similar, and punctuation templates would reduce readability of source text. MediaWiki takes care of translating source text characters into HTML entities when needed, and in my view we shouldn't try to bypass such feature except when really needed (see also Help:Template#HTML_entities). If you want to use some particular punctuation marks, IMHO you should enter them directly, possibly assigning them as special combinations to your keyboard map. -- Kynikos (talk) 06:00, 19 February 2014 (UTC)
Regarding source text readability, why not just input the unicode character itself — like this? (Notice that it works also for the hair spaces, though they are not very "hairy" in the source...) -- Lahwaacz (talk) 07:01, 19 February 2014 (UTC)
I would use those templates. :)
I agree that {{em dash}} would be less readable than a directly-entered "—" character; however, {{em dash}} is a lot more readable than &.#8202;&.mdash;&.#8202; (without the dots), which is why I support the idea. I feel that directly-entered em dashes with the surrounding hair spaces (using the Unicode characters directly) is less maintainable than {{em dash}} because subsequent edits may remove one or both of the hair spaces without editors realizing that they did so.
-- Jstjohn (talk) 01:14, 20 February 2014 (UTC)
Ok, I admit that to me all this seems overly complicated as in not Simple, however, as Help:Style/Formatting_and_Punctuation#General_rules says, "for cases not covered in this guide, Wikipedia:Wikipedia:Manual of Style is the authority reference", and to me it seems very sensible to stick with that rule instead of attempting to create our own punctuation guides. In particular, Wikipedia:Wikipedia:Manual_of_Style#Punctuating_a_sentence_.28em_or_en_dashes.29 says "do not use spaced em dashes", while they do have a {{spaced ndash}} template, so IMO that's what we should follow. -- Kynikos (talk) 14:21, 20 February 2014 (UTC)
If we decide for the templates way, which subset of the Wikipedia formatting and function templates should be used on ArchWiki?
I don't like the templates either, this had better be solved upstream (either directly in the parser core or via an extenasion. The only mention of upstream dealing with this I found is this rather old discussion, so it's probably going nowhere. (Extending the parser should not be that hard, a couple of regular expressions should do it for the dashes -- I'm surprised that it's not done yet...)
Suggestions so far: 1) use HTML entities (such as &mdash;), 2) use templates (such as {{em dash}}), 3) use the Unicode characters directly, 4) use some extension (none found yet), 5) drop the typography rules completely (use plain spaced hyphen " - " or commas) -- this could be called "wait for upstream to implement the necessary change" :P
-- Lahwaacz (talk) 16:43, 20 February 2014 (UTC)
Well, as I've said I'm for 3), with the possible advice of setting key combinations for the most frequent cases (e.g. AltGr + -I'm aware of 1 for the em dash). Just out of curiosity, _personally_ I tend to use ~5) because in my native language all the cases where English requires dashes are covered by commas or parentheses, so I'll be seen rarely, if ever, using dashes in my contributions.
Even if there was an extension to parse "--" and "---", we'd still find resistance for having it installed in our wiki... Maybe upstream they're just waiting for your patch! ;)
About Wikipedia's "formatting and function" templates, for sure we're discarding the "function" ones, and about the others I'd say let's create them one at a time whenever one is needed, but only if method 3) and method 1), in that order, would require too much typing effort for that case.
For completeness' sake, there's also a suggestion 6) to use a (theoretical) external editor that turns "--" and "---" into proper dashes before sending the text to the server, and does the opposite when retrieving a page for editing.
-- Kynikos (talk) 14:38, 21 February 2014 (UTC)
A little note, the Colemak layout already comes with en dash and em dash respectively preset to AltGr+- and AltGr+Shift+-. -- Kynikos (talk) 13:49, 10 June 2014 (UTC)

Rule suggestion: reference links

First of all, sorry if there is already some similar rule about this, I don't know (yet) what I've forgotten since last year :/

The suggestion:

"When adding troubleshooting sections to new problems, always add reference links into the article, whenever such links are available."

(There is (at least) one implied meaning: "...and not just in the edit summary" :) )

These links will be mostly links to our bug tracker or the forums. The rule should probably include some examples.

The reason behind this is quite obvious: the users (and maintainers) will easily know if the problem is still valid or already fixed.

Finally, some reference links for completeness: [25], [26]

-- Lahwaacz (talk) 21:48, 11 February 2014 (UTC)

The style guide should be currently freely editable, even though discussing any changes beforehand is a must (so thank you for doing it). You can go ahead and add a few examples, with the only recommendation to be as synthetic as possible, in accordance with the rest of the guide. -- Kynikos (talk) 07:09, 12 February 2014 (UTC)

Slashes in titles

It should be made clear that / in page titles will create a subpage, even if the parent page does not exist. Different wording (which must exist) should be used in cases where the subpage is not desired. While everything is working OK on the web interface, missing this detail will make alternative interfaces, e.g. arch-wiki-docs, quite confusing.

Some infamous pages suffering from this issue:

Additionally, I don't like the use of / even in section titles, it just looks wrong: List of applications#Scans/Image.

-- Lahwaacz (talk) 19:42, 21 March 2014 (UTC)

Umm, technically what I just said is wrong - subpages are disabled in the Main namespace. See for yourself: add {{SUBPAGENAME}} to systemd/User and preview, it will return "systemd/User" and not "User". (Also notice the small navigation link below the title in Help:Style/Formatting_and_punctuation) $wgNamespacesWithSubpages is probably set to default value in Arch Wiki configuration.
See also wikipedia:Help:Subpages#Slashes_in_article_titles.
-- Lahwaacz (talk) 08:56, 22 March 2014 (UTC)
Yes, subpages are disabled in the Main namespace. /dev/shm works in XFCE simple Network Monitor applet because that article is in the Main namespace and slashes are not specially interpreted there, while they are interpreted as relative (to the current page) links in the other namespaces like Help_talk, hence the red link since Help_talk:Style/dev doesn't exist. You must prefix a link like that with a colon in order to turn it into an "absolute" link, like [[:/dev/shm]].
That said, do you still support mentioning subpages in the guide? And how exactly? Also, would you forbid slashes in section titles? (I wouldn't, but I'm open for discussing as always)
-- Kynikos (talk) 17:11, 22 March 2014 (UTC)
Well, we should either enable subpages everywhere (or just the Main namespace in addition to those currently enabled?), or avoid using the term "subpage" altogether: Help:Style#Title, Help:Style#Kernel module operations, ..., Talk:Arch systemd container, Talk:Dm-crypt, ... Is there too much harm in having S/KEY Authentication a subpage of S? Is there a way to disable the 'subpage' feature on specific articles? Alternatively, would it be even more confusing to rename the page to S KEY Authentication?
-- Lahwaacz (talk) 08:32, 23 March 2014 (UTC)
I tend to be against real subpages in the Main namespace, as they would prevent the normal usage of slashes in titles, as you note too. Wikipedia has the same configuration by the way (but uses subpages).
I understand that using the term "subpage" can be confusing if taken literally, but how would you call the practice of naming articles like "Beginners' guide/*", "List of applications/*" and so on?
S/KEY Authentication as a subpage of S would create a confusing link at the top of the page, under the title (IMHO more confusing than the current usage of the "subpage" term).
If there was a way to disable subpages per-page, it would be through mw:Help:Magic_words, but it looks like there's nothing for that (yet?).
Renaming articles like S KEY Authentication would mean enforcing the rule of avoiding slashes in titles, which is something I would be against... Unless we make use of DISPLAYTITLE to display the correct titles?
Finally, I refuse to open a report to change the configuration of the wiki before FS#35545 is implemented >:( (Please, anybody reading here, vote for it)
-- Kynikos (talk) 21:54, 23 March 2014 (UTC)
Interesting, [27] does not show the link below the title. Maybe because the parent page does not exist? -- Lahwaacz (talk) 22:51, 23 March 2014 (UTC)
Very interesting indeed, I've done a test here and the link does not appear if the super-page doesn't exist. This actually turns my preference towards enabling subpages also in the Main namespace. However we should patch LocalSettings.php for that, and FS#35545 is a blocker unfortunately. -- Kynikos (talk) 18:21, 24 March 2014 (UTC)
I have misunderstood Meta-Wiki entry yesterday; today I found the information in MediaWiki too, but Meta-Wiki adds an interesting detail about breaking the breadcrumb links sequence on first non-existent page.
Wikipedia describes that they originally used subpages, but then switched to the disambiguation system, which probably lead to disabling subpages by default. We don't use disambiguations, so I don't see any further reason why the Main namespace should behave differently.
FS#35545 is the blocker, but we won't get anywhere without submitting another bug - it could be the necessary catalyst. (About [28]: you've won two votes since yesterday :)
-- Lahwaacz (talk) 19:31, 24 March 2014 (UTC)
You're absolutely right, I'll let you open the report since the idea and the research are yours; it would be better if you could restate the supporting arguments there instead of linking here, and finally emphasize the fact that a patch will be provided if FS#35545 is implemented first (if we manage to have it fixed, it will be very very useful in the future).
-- Kynikos (talk) 18:08, 26 March 2014 (UTC)
Reported in FS#39668. -- Lahwaacz (talk) 00:03, 29 March 2014 (UTC)
Added my vote. -- Kynikos (talk) 14:30, 30 March 2014 (UTC)

Storing pages on a file system

[This discussion started from the main branch in #Slashes in titles and was separated as being off-topic.]

I'm looking for a way to store the articles structure on a file system, to be used in arch-wiki-docs. Currently the script creates a subpage for every article containing "/" in title and replaces spaces with underscores, but S/KEY Authentication should be treated as "S_KEY_Authentication". Of course there is no way to determine if the page is really a subpage, and converting all slashes into underscores totally kills the tree structure (plus there would be additional work to make links work).

-- Lahwaacz (talk) 08:32, 23 March 2014 (UTC)

Have you considered encoding the file names, or at least the slashes? E.g. S%2FKEY_Authentication. -- Kynikos (talk) 21:54, 23 March 2014 (UTC)
It's probably the only way to force ASCII filenames maintaining human readability for most pages, but it's not really safe - Одновременная работа Интернета и бесплатной сети (ФОС) (Русский) is encoded into a 343 bytes long string instead of the original 117; the filename length limit for Btrfs is 255 bytes. Such pages should be moved directly on the wiki to comply with Help:I18n#Article_titles, but the margin is still very low. -- Lahwaacz (talk) 21:09, 31 March 2014 (UTC)
I don't think you should rely on the article names to have a specific length or character set on the wiki, also because localized titles may be allowed in the future. I would instead catch any exception when saving the file on the file system (or do a pre-check), and properly truncate the file name (maybe keeping the language tag?) and fix the links to it. -- Kynikos (talk) 00:26, 2 April 2014 (UTC)
For now I'm converting the (localized) language suffix into a language code prefix (ASCII), which solves the most of it, the problem is only with the anomalies. Of course if localized titles are allowed or someone will want to use the script for another wiki, changes will be needed.
At the moment the "safe-mode" is needed only for packaging, and assuming the packager uses unicode locale, catching file system errors will not help. Also the file name should be based purely on the title.
I think I'll use some common hashing function for the non-ASCII titles (and leave the ASCII alone), the readability will be the same as for URL-encoded titles, with fixed length and probably also sufficiently collision-free. The only disadvantage is that titles containing a single unicode character will become unreadable, but I'll have to live with that.
-- Lahwaacz (talk) 19:17, 4 April 2014 (UTC)
Closing - off-topic branch, already solved. -- Lahwaacz (talk) 09:44, 5 July 2014 (UTC)

Localized subpages

If FS#39668 is implemented, we should probably rethink the rule for localized subpages in Help:I18n#Article_titles. The problem is that with Title/Sub-page (Language) the breadcrumb links below the title will point to the English page instead of the localized one. Title (Language)/Sub-page makes more sense wrt file system hierarchy anyway, so I would do it anyway. Alternatively we may go the language namespaces way, which should also solve this problem. -- Lahwaacz (talk) 19:30, 4 April 2014 (UTC)

My original intention behind the Title/Sub-page (Language) style was to make it safer for Wiki Monkey to detect the language of an article by just looking at the end of the title, but I guess I might as well look for the tag anywhere in the title, and realistically it wouldn't give any troubles, so when FS#39668 is implemented we can indeed change the rule and rename the affected articles. The language namespaces way is still my long-term-preferred solution though. -- Kynikos (talk) 01:40, 5 April 2014 (UTC)

Formatting of references to man pages

[Moved from Help talk:Style/Formatting and punctuation#Formatting of references to man pages -- Kynikos (talk) 03:24, 29 June 2014 (UTC)]

How should references to manpages be formatted? Possible formats:

  1. pacman(8)
  2. pacman(8)
  3. pacman(8)
  4. .....see pacman manual.....
    or even maybe
  5. man 8 pacman

axper (talk) 16:53, 28 June 2014 (UTC)

Ok, let's standardize this, I think the clearest is "... see man pacman for details ...": the formatting complies with Help:Style/Formatting and Punctuation#CLI lines where it's already used as an example. I would leave the section number optional, it's quite rare that the same name is in two different sections, so we can recommend to specify it only in cases of ambiguity.
Let's read more opinions. -- Kynikos (talk) 03:34, 29 June 2014 (UTC)
I am ok with man pacman.
  • Newbies who haven't encountered manpages yet (which I think is rare) can simply run the command and not wonder what pacman(8) is.
  • It implies that manpages should be read via man. There are some great alternatives out there or may appear in the future. Of course users of these alternatives can run the equivalent command, but still.
Other thoughts: For popular manpage it's not very rare when one with same name is in different sections (crontab, man, intro, kill, link, locale, passwd, time, write, hostname). When a section isn't specified, this is the search priority:
  • 1 or 8 - executables or system executables
  • 3 - library calls
  • 2 - kernel calls
  • 5 - file formats
  • 4 - special files (/dev)
  • 6 - games
  • 7 - misc
So we should be a bit careful when not specifying the section number. Though this shouldn't be a problem as the author has probably ran the command himself and means the first one in the priority list.
EDIT: If the user is using one of the alternative viewers and section number isn't specified, that can cause problems for multi-section pages. axper (talk) 07:08, 29 June 2014 (UTC)
It is good to consider users with alternative viewers as you do, but using one is an explicit choice. Hence, it seems fair to imply the user knows how to use it as a man replacement. From the alternatives referencing the section in brackets only those having the section bracket outside the ic tag would be workable. However, we generally want to give the man reference prominence and for that a "see man passwd for options" is more prominent than a "see passwd(1) for options". That said, I'd personally like the non-ic version because it is a better textflow in my view. Plus the prominence the ic-tag gives is watered down the more it is used for peripheral commands.
For the reason you give regarding the author (the editor deciding whether man 5 passwd or man 1 passwd is referenced) it seems safe to leave it optional like Kynikos suggests.
To add another thought: In special cases it may even be helpful to reference it externally, e.g. like passwd's manpage, particularly when it can be assumed the user has no access to it yet on the system itself. For example: we frequently have man references in the article preface, but referencing a package's man page at that early point (before the installation section) is not particularly reader friendly. The problem with external links is of course consistency, i.e. there are too many outdated external references. But most editors are well aware of that, I'd say.
So, with the exception of special cases, I am +1 to Kynikos' suggestion if a rule is made, but like to add that I don't feel a need for it to be standardised. --Indigo (talk) 09:44, 29 June 2014 (UTC)
Good point Indigo, we can't assume the manpage's package is installed. I'd say we can allow two versions of references to manpages:
  • If the package is probably not installed, use "see pacman's manual for details" with the recommendation to prefer linking to the official web representation of the manpage, if available.
  • If the package is probably installed, use "see man 8 pacman for details", with the possibility to omit the section number when not ambiguous.
  • If the manpage is linked in a See also section, use the normal See also style instead (discussed in #Manpages in "See also" sections).
Do you like it? -- Kynikos (talk) 10:19, 30 June 2014 (UTC)
Oh, fine with me. Thanks for working it out. I particularly like the recommendation towards referencing official package's web manpages too; very beneficial for content overall & software rolling forward. --Indigo (talk) 18:14, 30 June 2014 (UTC)

Lists, colons, indentation

As a continuation of Block quotations, let's clarify our position to multi-line blocks inside lists and indentation (definition lists without definition terms). I have slightly mentioned this in the previous discussion, and I'd like to finish it here.

The markup lists are designed to be simple, and apparently are unsuitable for more complex lists, e.g. with multi-line blocks inside. Wikipedia says: "Do not use lists if a passage is read easily as plain paragraphs." I think that most of the "incorrectness" on Arch wiki comes from disobeying this quote. We should probably recommend using the lists only in simple cases, one or two paragraphs in each item at most (use <br> tags to separate them).

Other common case, unfortunately falling into the non-simple category regarding markup, is that a note or tip is presented inside a list. The "common" syntax has been

* some text
: {{Note|text to note}}

but I've recently seen a number of edits changing it to

* some text {{Note|text to note}}

which is something I don't like, because even though the latter renders correct HTML, it makes the wikitext unreadable. As much as we don't like it, definition lists without definition terms are a feature, and the MediaWiki's manual is full of such tricks. To achieve a fully correct HTML output only with markup syntax, we would need to fix the parser/renderer anyway, so I think we should focus more on wikitext readability.

The only way to achieve correct HTML, is to use HTML tags in wikitext, which brings me to the next problem: [29]. The edit clearly breaks the (future) rule "Do not use lists if a passage is read easily as plain paragraphs.", so the problem is reduced to usage of manual numbering - is it acceptable or do we tolerate HTML tags in such cases?

-- Lahwaacz (talk) 08:11, 29 June 2014 (UTC)

I agree, look at this page broken by a "Translateme" template inside a list. axper (talk) 08:30, 29 June 2014 (UTC)
I've used the * some text {{Note|text to note}} trick several times myself, but after reading Lahwaacz's reasoning I won't anymore (when I'll remember), as I agree completely: we should aim for the cleanest source text that results in the wanted appearance of the page. If the generated HTML is not correct it's indeed a problem of MediaWiki, we shouldn't try to work around it.
Yes, we should encourage preferring paragraphs or even subsections to lists with long/complex items. About ordered lists, manual numbering looks quite ugly to me, and I feel the same about mixing HTML and wiki markup: I think most (hopefully all) of the cases where it would be needed are better solved in some other way. For example in the QEMU case reported above, the items of that list don't need to be numbered, bullets or subsections should be used. Another notable example is Arch_packaging_standards#Submitting_packages_to_the_AUR, where bullet points would be more appropriate.
-- Kynikos (talk) 10:49, 30 June 2014 (UTC)
Maybe we can create a template for items? I mean something like this:
* First item
* Second item
* {{Template_name|
Third item


*Fourth item
And there will be a good readability of wikitext as well as correct indentations
-- Kycok (talk) 07:47, 4 July 2014 (UTC)
This still seems too complicated to me. -- Kynikos (talk) 06:15, 5 July 2014 (UTC)
I don't think such template is possible, the blank lines would still break the list (test it for Template:bc without <nowiki> tags). All the templates for lists on Wikipedia work the other way, template arguments are turned into list items. See for example wikipedia:Template:Ordered list, but it relies on Lua scripting, which is not available on Arch wiki. -- Lahwaacz (talk) 09:42, 5 July 2014 (UTC)

See also links

This is a low priority discussion, more of a reminder, however I'd like to recommend a unified style for external links in See also sections, because at the moment the various articles are inconsistent about that. These are some options:

-- Kynikos (talk) 15:36, 1 July 2014 (UTC)

I vote for the first style. It's compact and IIRC already more popular than the other styles. axper (talk) 16:00, 1 July 2014 (UTC)
Agreed with axper, +1 to the first style. --Alad (talk) 18:28, 1 July 2014 (UTC)
I like the first style too. Also, I think this is how the Wikipedia does it. -- Karol (talk) 20:35, 1 July 2014 (UTC)
I'd prefer the first style too, but I forgot that links in See also section can be accompanied by descriptions, these are some examples of how the style can vary: Core utilities#See also, Secure Shell#See also, Systemd#See also, KDE#See also (funny), Xfce#See also, List of applications#See also. I haven't made up my mind yet. -- Kynikos (talk) 06:48, 5 July 2014 (UTC)
Meahwhile I've run into a non-standard section in Cursor Themes and I've changed it like this. -- Kynikos (talk) 03:01, 6 July 2014 (UTC)

Preferred subpage method


See also: #Slashes_in_titles --Alad (talk) 12:16, 2 July 2014 (UTC)

I think, current method (number one) is good. The third one is bad (for example, it's very bad for List of applications Utilities). You can add another method with colon symbol: Page:subpage. But I'm ok with the first one -- Kycok (talk) 07:56, 4 July 2014 (UTC)
As subpages are a feature of MediaWiki, the only way to have a full subpage experience is the first option. Unfortunately, it is currently disabled in the Main: namespace on Arch wiki (see #Slashes in titles). Until it is enabled, all options have equal weight, but using anything different than slashes does not make sense if we want to eventually switch to them. -- Lahwaacz (talk) 08:20, 4 July 2014 (UTC)
As Lahwaacz says, using the slash form is the way to go for forward compatibility, do we want to write a rule and already start changing the existing non-compliant titles (e.g. pacman tips)? The problem is that without the little navigation links under the title, it's not immediate to understand the meaning of the slash, especially for short titles, which at the moment look neater with a simple space. -- Kynikos (talk) 06:59, 5 July 2014 (UTC)
My vote goes for option #4 (using sections like Wikipedia):
  1. Doesn't to pollute the "Related articles" column with number_of_subpages2 lines (or equivalent) with added complexity of maintaining all that
  2. Doesn't pollute the category pages
  3. It's easier to find information (i.e. Ctrl+f or / or by looking at TOC)
  4. No confusion caused by non-existent separator character
  5. Is just simple. Remember KISS? :)
axper (talk) 16:08, 8 July 2014 (UTC)
OK, let's compare us to Wikipedia (see wikipedia:Wikipedia:Subpages for reference). Basically, it forbids using subpages in the Main: namespace. The history section states, that subpages were once used to create hierarchies of articles, but then it was superseded by categories and disambiguations. On Arch wiki, the hierarchy of categories was designed as a tree (although in practice with some "converging branches", see #Category pages - tree or otherwise?) and we don't use disambiguations at all. Unlike Wikipedia, so far this system works quite well on Arch wiki, which I think is mainly due to the type of content, amount of content and greater devotion and attention to detail of the Maintenance Team :)
Sometimes an article is too long to be kept on just one page, and the easiest solution is to split some section into a separate article, which will effectively create a subpage. I don't really see how this could be avoided without completely rewriting it, disambiguations or categories won't help here.
But I could agree that the usage of subpages should be regulated, for example PulseAudio/Troubleshooting would be good, while Kernels/Compilation/Traditional would be wrong (see the Wikipedia case). I don't know yet about Color Bash Prompt and something like Bash/Color prompt.
-- Lahwaacz (talk) 09:00, 9 July 2014 (UTC)

Case of template name's first letter

Currently both Uppercase and lowercase are popular. Compare this with this. I'd like this to be standardized. axper (talk) 18:42, 7 July 2014 (UTC)

In fact, it already is: Help:Template#Style -- Lahwaacz (talk) 18:49, 7 July 2014 (UTC)
Thanks, I didn't notice that. Probably Help:Template#Style should be added to related articles list here. axper (talk) 18:51, 7 July 2014 (UTC)
The style of Help:Template is somewhere between Help:Style and Help:Editing (it is linked to from both), we would have to link also to Help:Template#Escape_template-breaking_characters so I think that linking to the whole page from Help:Style#Template_pages is enough. -- Lahwaacz (talk) 19:02, 7 July 2014 (UTC)
Alright then. axper (talk) 19:04, 7 July 2014 (UTC)