:::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 ) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:32, 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 ) -- [[User:Kynikos|Kynikos]] ([[User talk: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'' [https://github.com/git/git/blob/master/Documentation/CodingGuidelines#L313]. This style makes it quite easy to know whether to use "Bash" or "bash", etc.

Revision as of 02:42, 11 January 2014

Read this first

Help:Style is an official document of the ArchWiki, and is protected so that only users with administrator privileges can edit it. 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 protection 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.

Edit summary

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

Style vs. Usability

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:

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: http://slash7.com/2006/12/22/vampires/.

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.

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)

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?

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.

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.

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)

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.

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".

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.

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

Daemons and modules wording

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

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 '''.

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.

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)

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)

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.

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

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)

Lists of related links

Inspired by [1], 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)

Definition of related link

Inspired by [2], 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)

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:

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:

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

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.

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

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.

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.

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:

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:

Let's leave Install uncreated for the moment: somebody may use it in installation instructions (Installpackage ...) 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 :)

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)

Implicit links

How would you like a rule similar to:

Try to avoid implicit links when possible. For example prefer "See the systemd article for more information" instead of "See here for more information".

Capitalization

Application name

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

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[3]. This style makes it quite easy to know whether to use "Bash" or "bash", etc.

Template name

I think capitalization in tags is important for coherence. Should we avoid {{pkg|package}} in favour of {{Pkg|package}} and {{Ic|command}} in favour of {{ic|command}} like they are used in Help:Style? -- Flu (talk) 18:00, 19 May 2013 (UTC)

Um, so you would propose to define, one by one, which templates should be used capitalized and which ones should be used lowercase? IMHO this is an exaggeration, at the moment I don't see the need for a rule like this; however let's see if somebody else adds his support here :) -- Kynikos (talk) 15:11, 31 May 2013 (UTC)

(Note that in case we suggested to use all templates lowercased, we should move all the existing ones that have non-initial uppercase letters in their name to full lowercase names) -- Kynikos (talk) 14:32, 2 June 2013 (UTC)

(Is it not sufficient to just correct the examples and tell "The lower case form is the correct one, any other is deprecated."?) -- Flu (talk) 15:41, 2 June 2013 (UTC)

For example Template:ic has {{DISPLAYTITLE:Template:ic}}, so why don't we just make rule to use the capitalization as shown on the template page? -- Lahwaacz (talk) 15:32, 4 December 2013 (UTC)

Um I think the examples in each template page are a better reference, as for novices it's more natural to infer capitalization from {{ic|code}} than from the title of the page. The rule is in Help:Template#Style now. Closing. -- Kynikos (talk) 09:40, 5 December 2013 (UTC)

Links

Which one is correct? [[official repositories]] or [[Official Repositories|official repositories]]?
I prefer the first because it is essential but somebody has a diffent idea apparently. -- Flu (talk) 13:13, 4 June 2013 (UTC)

I agree that [[official repositories]] is better. The only disadvantage(?) is that if you click that link, the page will say "Official Repositories (Redirected from Official repositories)", which can be considered ugly. To solve all problems: wouldn't it be better to rename Official Repositories to Official repositories? --Lonaowna (talk) 14:10, 4 June 2013 (UTC)

[[Official Repositories|official repositories]] would go straight to the right page, not following [[official repositories]], which is the redirect that Lonaowna mentions.

I too prefer the lower-case version, since IMO there's nothing to capitalize, both "official" and "repositories" are generic terms that mean something special only because they're put together.

In any case, redirects are not ugly :) Negative perception of redirects is something that comes out every now and then, but redirects are a good feature of a wiki also because they allow linking to an article using an alternative (though still related) text, without resorting to complicate links: if it was for me I'd recommend using [[official repositories]] over [[Official Repositories|official repositories]] as it makes the source text look simpler, however I know that this would be too much of a request for many editors.

Thanks for your opinion. I think [[official repositories]] is indeed the way to go, people (including me) will just have to live with the redirect. :) --Lonaowna (talk) 19:33, 4 June 2013 (UTC)

List of Applications and See also

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?

In the same list it may be fair to put {{Grp|group}} beside items that have their one.

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.

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.

White space

Blank lines

Very often there is a blank line after section headers in edit mode. It is clean, but it is not a standard. Should we use it as standard? -- Flu (talk) 18:00, 19 May 2013 (UTC)

Um I too would like to agree on a style rule for this: To be honest I like both ways, however I too hate it when it's not consistent throughout an article ;) is there anybody who wants to support the pro-blank-line style or the no-blank-line one? As for every other rule of this kind, I will be very reluctant to change it after it's been enforced. -- Kynikos (talk) 07:27, 29 May 2013 (UTC)

I'd also like to propose a rule/recommendation to add blank line between individual replies on talk pages (and avoid them in the post itself). This should greatly improve the readability of the code when replying in longer discussions. Compare: [4] vs. [5] (of course look at the code). -- Lahwaacz (talk) 16:23, 1 September 2013 (UTC)

Spaces

Well, if we write a rule for this, we should probably also define whether to support the ===Some title=== or the === Some title === form. Again, I don't have a preference. -- Kynikos (talk) 07:41, 2 June 2013 (UTC)

In general

I can also think of blank lines after article status templates, before/after code formatting templates etc... I think there's so much on white space that we could give guidelines for, we could probably write a separate article only for that :) Why not, however it's not urgent for the moment, but it can surely be done once we'll have decentralized the style rules as I've already mentioned in almost every discussion now :P -- Kynikos (talk) 14:19, 2 June 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.

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)

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

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.

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.

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

I didn't find any rule/official policy regarding talk pages of redirects, but you made me think about it.[9] 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 :)

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.

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)

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]][10] kind of confusing, it should be clear that the link points to a section on current page and not to separate page. Possibilities:

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

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)

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.

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: [11] (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 [12] with links to clone the repo. I'd be interested in giving a hand of course :)

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.

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?

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:

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.