Help talk:Style

From ArchWiki
Revision as of 04:29, 22 September 2011 by James Eder (Talk | contribs) (See also or Related in Article Summary?)

Jump to: navigation, search
Note: Besides being a place for discussing modifications to Help:Style, this page provides an example for the style to be used in all the talk pages around the wiki, therefore you should respect some basic rules aimed at keeping things tidy:
  • Add new discussions at the bottom of the page and with a proper heading;
  • Indent your answers using colons at the beginning of new lines;
  • Always append a signature to your edits.


Discussing the guide itself

In this section you can discuss modification to the Style Guide itself.

Initial references

This talk page could soon need to be split in sub pages

Based on the subject of the discussion. -- Kynikos 09:32, 3 May 2011 (EDT)

Maybe better having one subpage for each section in the main article? -- Kynikos 09:53, 3 May 2011 (EDT)

Let's move any looong section to a subpage to make it easier to comprehend. -- Karol 13:34, 9 May 2011 (EDT)

Add new discussions at the bottom of the page and with a proper heading.

Maybe explicitly point to the '+' tab between 'edit' and 'history'? -- Karol 12:15, 3 May 2011 (EDT)

OK, I see one problem: it uses '==' headings and you may want to use '===' ones. -- Karol 12:18, 3 May 2011 (EDT)
For one thing you are right, at the moment it should be "at the bottom of the 2nd level section" (like this one), not "of the page". However changing it would sound kind of weird... I don't know.
The problem of the '+' tab is unsolvable until we keep discussions on 3rd level here. Let's not forget about this suggestion when we split this page into subpages. -- Kynikos 12:32, 3 May 2011 (EDT)

Schematic vs verbose guide

I'm in favour of reporting the rules in the guide in a schematic (I'm not sure if this is the right word) way, avoiding long descriptions and making extensive use of subsections, lists, definitions and even tables if necessary, and using brief examples and counterexamples. Opinions? -- Kynikos 07:28, 17 September 2011 (EDT)

I'm fine with schematic way, as long as it's comprehensible, complete and doesn't contradict itself. -- Karol 09:00, 17 September 2011 (EDT)
I think there is merit in keeping the article terse and pithy. The "TLDR" bunch are plenty and it seems the TL threshold is getting shorter all the time. I could go to great lengths about being terse but... :P James Eder 13:18, 17 September 2011 (EDT)
Oook, schematic wins :) Don't look at how the page is organized atm, I'm still trying to find a good layout for the rules. -- Kynikos 05:48, 18 September 2011 (EDT)

Demo template

How do you like the demonstration template at the top of the page? (The stub is meant to be removed) I'm asking because I'm undecided whether it's useful or not. -- Kynikos 07:00, 18 September 2011 (EDT)

I think it’s distracting, and probably only relevant to the “Article status templates” section, not the whole page. Vadmium 01:29, 19 September 2011 (EDT).
Uhm right, I added it because my initial, raw idea was to try to write the rules in the same elements which they were referring to, but I abandoned it quite soon, so now the template is useless, even in Article status templates. -- Kynikos 06:11, 19 September 2011 (EDT)

Style rules

This section is for discussing the addition or modification of style rules.


All articles should belong to at least one category in Category:Pages sorted by topic (English) and one in Category:Pages sorted by type (English) otherwise it does not make sense to talk about "sorting". This should apply to categories themselves, in a way to create a consistent category tree. An article can belong to more than one category, provided one is not parent of the other. Agree? Don't agree? -- Kynikos 09:32, 3 May 2011 (EDT) User and talk pages should never be categorized instead. -- Kynikos 09:55, 3 May 2011 (EDT)

I plan to eliminate Category:Pages sorted by type (English). Category:General (English) is not helpful; Category:HOWTOs (English) is somewhat redundant (and ArchWiki is moving away from the how-to style; Category:FAQs (English) contains very few articles (of which most should be merged with FAQ); and almost all pages in Category:Guidelines (English) relate to packaging.
I hope to initiate a discussion and propose my plan in more detail in Talk:Table of Contents this weekend.
-- pointone 22:47, 4 May 2011 (EDT)

Edit summary

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)


Never use first level headings (=, used automatically for the main article title), always start the tree from second level (==). Link to Effective_Use_of_Headers -- Kynikos 11:46, 3 May 2011 (EDT)

Package installation

pacman -S package vs pacman -Syu package: already started discussing in User talk:Kynikos#"pacman -S foo" vs "pacman -Syu foo" and User talk:pointone#"pacman -Syu package". Probably a nice subject for a new thread in the forum? -- Kynikos 11:46, 3 May 2011 (EDT)

Agreed; this should be discussed with the community at large. -- pointone 22:56, 4 May 2011 (EDT)

[myusualbrainstormingmode ON]I would even add a third opponent: treat official package installation similarly to AUR packages: just list the packages to be installed (possibly with Template:Package Official) and link to Pacman or some other article for details on how to install.[myusualbrainstormingmode OFF] -- Kynikos 05:23, 17 May 2011 (EDT)

Ah, and maybe rename Template:Package Official to Template:Package or just Template:Pkg for ease of use. -- Kynikos 05:32, 17 May 2011 (EDT)

I agree! I don't think we should use the verbose "Install Template:Package Official: pacman -S pkgname" outside of the Beginners' Guide. "Install Template:Package Official." should be enough, and I don't think we need to link to pacman each time we do it, since archers learn how to install packages during the initial install. Explicit instructions are useful when it's not something completely obvious, like using --asdeps or -D. thestinger 05:48, 17 May 2011 (EDT)
Well the link could be implicit, like in "Install Template:Package Official". -- Kynikos 06:03, 18 May 2011 (EDT)
I think we could have a template for that too. Something like {{install|pkgname}} which would render as: "Install the Template:Package Official packagehow?" Bonus points if the template can accept a list of packages. I think the "how?" is small enough to be ignored by the more experienced but friendly enough for the novice. One could have a separate template for AUR packages which links to the AUR Wiki article instead. James Eder 17:19, 3 June 2011 (EDT)
Is there a way to use templates and point to a specific package? This is not what I want, I want just kernel26. Selecting only core repo makes it a bit better, but still not perfect. This method can cause some confusion so it would be nice to avoid it. -- Karol 18:06, 3 June 2011 (EDT)
I don't know if there is a way but it seems in most cases the right package appears at the top of the search results at least. On the other hand, most users probably are going to be using pacman to grab their package anyway. In that case, linking to the web front end for the database might not be that useful anyway. James Eder 19:24, 3 June 2011 (EDT)
About the template, I have the same position as for the daemons: it would force to use always the same wording while there are cases which would require different, more natural ways of explaining the installation. For example what would you do with optional packages? Would you make a Package Optional template? And with lists of packages? As far as I know, templates don't support for loops, so how would you print a list of packages with a single template?
About Karol's question, I think that the main problem would be the difference between i686/x86_64 and any packages: this would require 2 templates, unless we'd like to provide only one package in case it's a i686/x86_64 type. Apart from that, each package has a well defined URI, so it would be easy to compose it providing as arguments the package name and the repository.
Anyway, as stated by Pointone, all "this should be discussed with the community at large", e.g. in the forum I guess. -- Kynikos 10:20, 4 June 2011 (EDT)

Related: #AUR package installation

Let's sum up this discussion:

  • Package installation instructions should be given as "Install Template:Package Official, available in the [reponame] repository". The alternative is a template for doing this.
[discuss here...]
  • Do we enforce also mentioning the repository? This will have to be maintained in case the package is moved somewhere else.
[discuss here...]
[discuss here...]
  • Allow using direct links to packages to avoid ambiguities?
[discuss here...]
  • Create a template which composes a direct link when given repository name, architecture and package name as arguments?
[discuss here...]

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

Standard headings

"External links" vs "See also", "Troubleshooting" vs "Known issues" (keep both? as there is actually a difference in meaning). -- Kynikos 12:01, 3 May 2011 (EDT)

An "External links" section is really a narrower class of "See also." I do not see much of a point in making the distinction as a separate section of the article. External links already have extra markup applied to them (the box and arrow icon) and link titles can and be made fairly obvious as to what they link to. I propose we just standardize on "See also" sections. As an added benefit, "See also" has a more imperative tone suggesting that the user should in fact see them.
WRT "Troubleshooting" and "Known Issues" sections, I'm fine with an article that has both. Troubleshooting generally covers problems the user can fix while "Known Issues" may cover issues which the user may not be able to do much about (due to bugs and such that must be addressed by developers, for example). James Eder 15:44, 3 June 2011 (EDT)
Implemented. -- Kynikos 11:48, 20 September 2011 (EDT)

Article summary templates

Article summary templates provide a place to sum up the content of the aricle. The problem is that, in my opinion, this conflicts with the text written in the first part of the articles, before the first heading, which is kind of used for the same purpose. You can see this even in the page I've linked at the beginning of the paragraph, and in Writing_Article_Introductions. I suggest that the summary should only be written as normal text before the first heading, and that Article summary templates should be used only to provide additional schematic introductory informations, like links to related articles (also note that this could conflict with "See also" sections), using the Overview templates, listing packages to download (like in Trinity) and so on. Writing Article Overviews and Writing Article Introductions should be edited in accordance, or maybe merged with this very article? (They actually talk about style) -- Kynikos 12:12, 3 May 2011 (EDT)

I never liked those summary templates and I prefer to have all the related links either in the article itself or at the bottom in the "See also" section. The introduction should have info like This is an article about foo. If you're looking for foo2, go to this page and if you want bar, go to this page. Examples Gnome v. Gnome 3, Virtualbox v. Arch Linux VirtualBox Guest. -- Karol 13:24, 3 May 2011 (EDT)
Would you definitively deprecate Article summary templates? It would KISS things up, I could agree.
Let's try to be concrete, otherwise discussions like this can last for eternity: I'm listing all the possible uses for Article summary (add more if you can think of others), then evaluate each briefly to see if it can be put back in the "normal flow" of the article:
  • Article summary:
it could easily (and I think should) be always substituted by the text before the first heading (which appears before the ToC);
  • Overview template:
more hardly replaceable, unless we just list its links in the See also section and get rid of the rest of the description; I don't like Overview templates very much, they could also be included in the normal summary at the beginning of the article;
  • Related articles and other links (Wikipedia articles, Series, Changelogs...):
easily mergeable with the See also section, anyway I don't know if I would like the opposite more;
  • Legal info:
This is rarely used (Fonts is the only occurrence I've found with a brief random search); it could be easily integrated in the normal flow;
  • List of packages:
Also rarely used (Trinity is the only occurrence I can think of at the moment); it could be integrated in the normal flow, though a long list would not look as good.
  • ...?
In the end, I would start removing the conflict for the summary itself, and then take care of the rest, also because a lot of articles make use of these templates in various ways.
As always the last word will come from the administrators. -- Kynikos 17:54, 3 May 2011 (EDT)
In my mind, the introduction should be used to describe the topic of the article whereas the summary should be used to describe the structure and scope of the article. E.g. Introduction: X is an application that turns your computer into a killer robot. Summary: This article covers installation and configuration of X. A slight distinction, I will admit. (Analogy: abstract versus introduction in research articles).
I created the overview templates as a way to add context to the related articles. Yes, article X is related to Y, but in what way? I also prefer seeing related links at the beginning rather than the end of articles.
-- pointone 23:03, 4 May 2011 (EDT)
Well I agree about the links: as we are trying to standardize the style you could consider approving to move all links from See also and External links sections to the Summary box.
About introduction and summary, I still think the difference is really too subtle to be noticed and applied in all the articles without having to puzzle over what to write where. We should think well if it really gives an advantage to have the two kind of text separated; also IMHO the purpose of the summary, as you have descripted it, is almost completely fulfilled by the Table of Contents. -- Kynikos 10:36, 5 May 2011 (EDT)
I’m not really a fan of these floating templates either. I tend to start reading a page sequentially, at least until I get a feel for what the page is about and decide if I am reading the right page or not. I ignore these sort of floating boxes because they don’t visually have a place in the main text sequence. I often just assume that if they contained important information, that information would be present in the main body as well. Perhaps I would take more notice of these templates if they were on the left (since I read from left to right), but on the other hand perhaps that would make me even more annoyed at the pages that use those templates :P.
How do the templates help add context to related articles? Vadmium 06:13, 1 August 2011 (EDT).

Is the Article Summary to be optional or required (mandatory) on every article? And if it's optional, the choice is purely based on authors' preferences or do we suggest some guidelines? -- Kynikos 07:02, 17 September 2011 (EDT)

A crazy idea (about Summary templates, Overview templates and categories)

[Brainstorming mode ON]I don't even know if this could be feasible at all, but what if we could instruct the Article summary template to "read" (with an internal inclusion like those in the Beginners' Guide?) a specific standard section in each Category page that the article belongs to? That standard section would contain a description of the category, and that could somewhat replace the Overview templates. (How hard it is to explain insane ideas, further clarifications could follow)[Brainstorming mode OFF]. -- Kynikos 12:43, 3 May 2011 (EDT)

This is an example: looking at the code, I have used Template:Graphical user interface overview, but with this method its text would be in the includable section (Overview) of the Category, and would be included (automatically with some template hacking?) in the Summary template field:

Lorem Ipsum

Category: Desktop environments

{{:Category:Desktop environments}} (Would this work?)

Template:Graphical user interface overview


External links

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin egestas, magna non sollicitudin commodo, sapien elit semper sapien, adipiscing consectetur nisi ipsum ut elit. Sed ac neque ut nulla tempor porttitor. Mauris interdum. Cras feugiat sodales nibh. Proin neque turpis.

Categories: Desktop environments


Category:Desktop environments



Template:Graphical user interface overview







This way every category would have a brief description, Overview templates would become unnecessary (merged with category pages), all (categorized) articles would have an almost automatic overview, and people would be more willing to categorize pages well. -- Kynikos 06:02, 5 May 2011 (EDT)

Ok, this definitely works: see Template:Sandbox, Category:Sandbox and Sandbox for an example (Note that Template:Sandbox has been edited meanwhile, so the examples don't work anymore at the moment. -- Kynikos 08:22, 15 May 2011 (EDT)). My suggestion would be an Article summary category template, or just Category to be put among Article summary templates; note that it automatically adds the page to the category, so it doesn't even duplicate its name in the source.
Template code:
<includeonly>{{Article summary heading|Category: {{{1}}}}}
{{Article summary text|[[Category:{{{1}}}]]{{:Category:{{{1}}}}}}}</includeonly>
[[Category:My category]]

{{Article summary start}}
{{Article summary text|bla bla bla}}
{{Category|My category}}
{{Article summary heading|Other heading}}
{{Article summary text|bla bla bla 2}}
{{Article summary end}}
[[Category:My category]] is not needed at the top of the page. -- Kynikos 09:56, 5 May 2011 (EDT)
Of course if there's some category text that needs to be prevented from displaying in the template, it should be enclosed in <noinclude> tags (see the source of Category:Sandbox for an example). -- Kynikos 10:42, 5 May 2011 (EDT)
My original plan with respect to overviews was to include them on their related category pages (category summaries). I, too, thought of something similar, but realized that many existing categories are too broad. Consider Template:Access control overview, which includes pages under Category:Security (English). I also envision an "Encryption overview" which would fall under Category:Security (English). For this to work, we would need to split Category:Security (English) -- not necessarily a bad thing, but I believe the template system provides more flexibility. -- pointone 20:41, 10 May 2011 (EDT)
All this idea was built on the assumption that if two articles need two different overviews, then they very likely belong to different categories (possibly in a parent-child relation) and vice versa: in your example there probably should be an Encryption category, child of Security. I still think that the flexibility given by the Overview template system has a (IMVHO too high) cost in terms of ease of use and maintenance, with respect to the category system, anyway as I said it was just brainstorming. -- Kynikos 08:58, 11 May 2011 (EDT)

Introductions: de-duplication of effort

See also: #Article summary templates

I feel that rather than paraphrasing or writing your own (possibly biased) description of a piece of software, wiki editors should use the upstream/author's description of their own work. This can usually be found on the project's home page or about page, if it exists. An effort should be made to include such an introduction at the beginning of an article formatted as a block quote. Of course, editors may expand further, but the quotation provides a level of fairness and consistency (and a link to the project page). Example: MediaTomb

-- pointone 23:18, 4 May 2011 (EDT)

Implemented. -- Kynikos 15:39, 21 September 2011 (EDT)

AUR package installation

Avoid referring to a specific AUR helper or even to AUR helpers in general: use the makepkg-pacman -U way? -- User:Kynikos 13:31, 5 May 2011 (EDT)

I believe that simply linking to the AUR package and the Arch User Repository page is sufficient. Example:
Template:Package AUR is available in the Arch User Repository.
-- pointone 09:57, 6 May 2011 (EDT)
For me it's perfect. -- Kynikos 12:56, 6 May 2011 (EDT)

Related: #Package installation

Troubleshooting sections

To add or not to add temporary solutions for bugs? It's a good candidate for a style rule. What about letting add such workarounds in Known or Reported Bugs sections, requesting to add also a link to the bug report? Like here, for example. -- Kynikos 06:07, 7 May 2011 (EDT)

I think there should be a strong recommendation that workarounds for a problem include a link to a bug (Arch FS, upstream Bugzilla, etc). Most problems that are "fixed" with workarounds are in fact bugs weather they're a feature deficiency or otherwise. There are great benefits in linking to a bug report both for readers and editors:
  • For Readers: The Wiki doesn't become a stopping point (dead end) for the reader. The reader can find more information close to the source that may have otherwise been missed by reader's search efforts.
  • For Wiki Editors: It makes clean up easier by reducing the effort involved in researching the question: "Is this still an issue?" This can even lead to greater autonomy if the reader finds new information and comes back to edit the wiki.
  • For everyone: If there isn't a bug report, why not? Keeping the recommendation strong could encourage more fixing.
If the article links to a relevant bug report, I think it is fine and even desirable to include temporary solutions. One might make the further recommendation that the bug report be either an Arch FS, directly from the upstream. +1 James Eder 12:59, 30 June 2011 (EDT)
Implemented (summed up). -- Kynikos 11:52, 20 September 2011 (EDT)

Strongly discourage use of html-style comments in the wiki code

Instead of writing e.g. <!-- Somebody really needs to fix this, it doesn't work for me. --> add notes or warnings and discuss the issue on the article's discussion page. Do we want to include such obvious stuff in the Style Guide? -- Karol 13:31, 9 May 2011 (EDT)

Yes; this guide is (or should be) intended for those new to wiki editing. I've seen this often enough to warrant inclusion here. On a similar note, instead of writing somebody really needs to fix this (without comments) add accuracy flags and discuss the issue on the article's talk page. -- pointone 20:01, 10 May 2011 (EDT)
Just checking, is using html comments <!-- {{i18n|MEncoder}} --> to hide the i18n element if the article exists in only one language is still bad? -- Karol 05:46, 1 June 2011 (EDT)
This issue is (or will be) covered by #One-link i18n templates. -- pointone 07:48, 1 June 2011 (EDT)
Implemented. -- Kynikos 11:59, 20 September 2011 (EDT)

Wrap long lines in the code output

Karol 13:31, 9 May 2011 (EDT)

I think Karol was referring to edits that add <pre style='overflow:auto'> around code fragments. It allows the text to be scrolled independently of rest of the page. I think this is sometimes better than having to scroll the whole page.
But where possible, wouldn’t it be even better to write the code without long lines in the first place (one line per step; use newline \ escaping; etc)? In situations where this is not possible, I’d generally prefer enabling word-wrapping and point out that the code is meant to be on a single line. Depending on the browser, this should still be easy to copy and paste, but also be better for printing a hard copy, and if the code is vertically long it avoids the code’s horizontal scroll bar being hidden by vertical page scrolling. Vadmium 02:30, 1 August 2011 (EDT).
I don't dislike overflow:auto in code blocks, selecting a long line is easily done with triple-clicking on modern browsers. I think the major downside is when printing, as you pointed out, but that could be handled with specific css using <STYLE type="text/css" media="print">
Maybe I waffled on a bit about the printing which is probably not very important. My main point was that if the wiki recommended something to work around excessively long lines, that should be a last resort and it would be preferable to avoid the long lines in the first place. Vadmium 06:24, 1 August 2011 (EDT).
Agreed, however line breaking should be completely manual, and not devolved to automatic word-wrapping (not even with an explanation that the code is meant to be on a single line). That's why by default I'd rely on overflow:auto. -- Kynikos 05:52, 2 August 2011 (EDT)

Prepare examples of both simple and advanced use of the (new) wiki templates & formating

so users can easily figure out how to get what they need and not get stuck with ugly stuff like this: Template:Cli

I've added <nowiki> tags and it already looks better:

Template:Cli I'm not sure if this idea belongs in the Style Guide and if the new templates will need much explaining :-) -- Karol 13:31, 9 May 2011 (EDT)

I'm not correcting edits like that, because I have faith the Age of the New Templates will come :P -- Kynikos 13:07, 10 May 2011 (EDT)
I too shall eagerly await its arrival ;P -- Karol 13:42, 10 May 2011 (EDT)

If possible, automatically escape any disallowed character in the templates

like '=' in the urls. We can't simply <nowiki> the whole thing, because we want to keep the urls clickable . -- Karol 13:31, 9 May 2011 (EDT)

I don't think this is possible with our current wiki configuration. -- pointone 20:25, 10 May 2011 (EDT)
I think he meant to suggest using HTML escape characters in templates (and other breakable features?) like &#61; for =. I'm in favour. -- Kynikos 05:14, 11 May 2011 (EDT)
Let's not forget that if the name of the argument is specified (or its numeric value), the equal sign won't break templates, as in:
{{Tip|1=Example []}}
-- Kynikos 08:03, 6 June 2011 (EDT)

Related: ArchWiki:Requests#<tt> is deprecated in HTML 5 (closed discussion).

I think the methods to escape characters should be explained in Help:Editing rather than here, right? -- Kynikos 15:56, 21 September 2011 (EDT)

One-link i18n templates

Should there be a style rule for inserting i18n templates (a recent example among many) when there is only one version of the article? The advantage is more coherent-looking pages; the disadvantage is that the template is actually useless that way. I don't have a position yet. -- Kynikos 05:14, 11 May 2011 (EDT)

One-link i18n templates are standard, closing. -- Kynikos 09:38, 19 September 2011 (EDT)

Editing file standard

Do not assume a specific text editor (nano, vim, emacs....) when requesting text file edits, unless strictly necessary. (Source: User:Pointone/Style_Guide) -- Kynikos 09:58, 13 May 2011 (EDT)

Do not use implicit commands to request text file edits, unless strictly necessary. Example (taken from an old revision from Disable Clearing of Boot Messages):

$ echo -e "clear\nreset" >> ~/.bash_logout

Should better be:

Append the following lines to Template:Filename:


-- Kynikos 09:58, 13 May 2011 (EDT)

rc.conf arrays

When adding to DAEMONS, MODULES, etc. don't paste extraneous code in the example; don't background by default. (Source: User:Pointone/Style_Guide)

Use File template?


Add dbus to the DAEMONS list: Template:File

DAEMONS=(!hwclock @dbus @ntpd)
DAEMONS=(... dbus ...)

-- Kynikos 09:58, 13 May 2011 (EDT)

Thestinger has another idea. -- Karol 00:56, 15 May 2011 (EDT)
I see, but shouldn't he better discuss such radical changes first like we're doing here? Of course I don't like it that way, as it shows extraneous daemons, though that could be easily fixed. Anyway using such a template would have the disadvantage of a loss of flexibility, for example how could you make the template accommodate for cases like this?
It has also to be noted that at the moment that template can be used only in articles which already make use of the Cli (and File) template, otherwise it will look ugly; this won't be true any longer when there will be official rules for style.
Tell me your opinion, and then maybe we could invite Thestinger to discuss here. -- Kynikos 08:22, 15 May 2011 (EDT)
The problem with a free-flowing wiki is that instead of fixing something in one place, you need to do it in a dozen places and you can't be sure you got them all. Templates are a way of lessening the maintenance burden unless they themselves are a PITA :-) He wrote that this template is not (yet) intended for all daemons, since some may need to be started before network, and some after (along with other conflicts, such as networkmanager v network). and he's working on some better ones.
I would just keep a wiki section on how to add, remove / disable (!foo) and run daemons (rc.d foo ...) and then just write "Add foo to the DAEMONS list" w/o any templates or use some generic ones if it's more complicated than that, so basically I'm with you on this. You can use his talk page or e-mail him and ask to join us here. -- Karol 19:37, 15 May 2011 (EDT)
I've just left a message on his talk page. The article about daemons already exists, it could be linked in a similar fashion to how AUR packages installation has been discussed to be handled. -- Kynikos 12:39, 16 May 2011 (EDT)
Hi, I ended up making the template only because it seemed silly to manually sync the dbus instructions given on a bunch of pages. I definitely agree that it should be handled like AUR installations with a link to generic instructions (that you only have to learn once) but I didn't feel comfortable replacing the instructions without any consensus. The page should just have info specific to the daemon, such as dependencies on other daemons. thestinger 18:12, 16 May 2011 (EDT)
I see. Trying to adapt Template:Daemon to all the possible scenarios could lead to a template even more complicated to use (if possible at all) than simple text. I think that before starting to change how daemons are treated in the articles, we should find a "definitive" solution here, with the approval of administrators. -- Kynikos 05:18, 17 May 2011 (EDT)
This is why I don't like the template way: it forces to use always the same phrasing and to renounce using much more natural expressions; for example with this edit we lost the explicit request to prevent hwclock from starting in rc.conf. -- Kynikos 06:06, 22 May 2011 (EDT)
reverted back to the old way, I agree that templates aren't going to work for this. thestinger 20:29, 22 May 2011 (EDT)
In the next days I hope I can find the time to start implementing in the main article some of the ideas in this talk page, so we have a more concrete basis for duscussing. -- Kynikos 11:29, 23 May 2011 (EDT)

Acronyms in titles

When the subject of an article is known with an acronym, always use the full name in the title, or the acronym? Or decide case by case? -- Kynikos 11:24, 23 May 2011 (EDT)

Can you give an example where you think it's better to use an acronym? -- Karol 17:33, 23 May 2011 (EDT)
Uhm GNOME and GRUB are the first ones that I could think of, technically they are acronyms :) I think deciding case by case is my preferred option. -- Kynikos 06:11, 24 May 2011 (EDT)
Hmmm, I guess you're right. BTW, thanks for reminding me how to link to Wikipedia articles ;P -- Karol 07:57, 24 May 2011 (EDT)
Do we leave the choice to the authors or do we enforce rules for using full name instead of an acronym e.g. in all Arch Translation Day articles - ATD_5.2._2011_(Česky)? -- Karol 01:01, 25 May 2011 (EDT)
As I said (my opinion), decide case by case, and create redirections if they can be useful. -- Kynikos 05:19, 25 May 2011 (EDT)
When in-doubt, the inclination should be toward expansion of acronyms in titles. However, as pointed out, flexibility is necessary here. -- pointone 17:25, 6 June 2011 (EDT)

Using both the full name and the acronym (e.g. using parenthesis) should be avoided. -- Kynikos 11:24, 23 May 2011 (EDT)

When one form is chosen, for the other(s) should be created redirections to the main article, to facilitate searching for it. -- Kynikos 11:24, 23 May 2011 (EDT)

Notes, Warnings, Tips

Define non-overlapping scopes for these templates. -- Kynikos 18:06, 27 May 2011 (EDT)

Do not privilege one shell over the others?

Inspired by this edit, I'm wondering if articles should always assume bash as the user's shell or be as neutral as possible (note the default shell is indeed bash). -- Kynikos 08:11, 29 May 2011 (EDT)

I think in such cases there should be info about other shells too and possibly a universal method - one ring config to rule them all. -- Karol 08:28, 29 May 2011 (EDT)
(The heading of this discussion was misleading, I've changed it)
I was more thinking of avoiding the use of headings like "~/.bash_profile", and if the code is different between the shells (not in this case), use subheadings or an unordered list. -- Kynikos 05:16, 30 May 2011 (EDT)

Do not use <pre> for highlighting

Do not use <pre> for highlighting text. -- Kynikos 18:39, 2 June 2011 (EDT)

Do not use <pre> for one-liners

Example of what not to do. IMHO it's better to start that line with a space. What's your opinion? -- Karol 05:31, 3 June 2011 (EDT)

I don't think we have many cases where you should be using a one-liner with a space or <pre> - we have the Cli and File templates which cover one-line commands and lines in a specific file. thestinger 11:42, 3 June 2011 (EDT)
I don't like the Cli template for many reasons (I don't like the colors, the need to escape some characters, it doesn't use <pre> to render) but maybe the new templates will make me change mind mind :-) -- Karol 12:43, 3 June 2011 (EDT)
I've seen <pre> used for one-liners in ordered/unordered lists. I left them partly because they also work around the quirkiness of having more than one block element (paragraph) per list item. (<br> works too but I don't care for that much either since it breaks whatever style sheet type stuff you might have in place for spacing between paragraphs.) The other reason I left them is that the File and Cli seem too bulky for short one-liners. It's not so bulky/ugly that I'd consider removing the templates if they are used for one-liners, but I'm indifferent and lazy about adding them for short 1~3 line spans. James Eder 13:04, 3 June 2011 (EDT)
I'm not sure if Thestinger and James followed the discussions about templates restyling, so I'm reminding you they are linked at the top: we tried to find some ways to standardize and simplify the usage of Cli, File and similar templates, but I haven't had the time yet to sum them up in this page. -- Kynikos 10:29, 4 June 2011 (EDT)
How about we just have a rule "Avoid unnecessary uses of <pre>. It is generally preferred to simply begin a line with a space which often has the same effect. See [[Help:pre]]." The article link at the end would link to an article (or some article section) about the differences between <pre> and lines beginning with a space:
This is a <pre> block. '''markup does not work here'''. <b>test</b>
Note: the HTML tag causes the use of a fixed-width font and preserves whitespace. In the
Wiki it additionally causes markup to be treated as plain-text.
This line begins with a space.  It has similar appearance to a <pre> block but is still
affected by markup: bold text italic text wiki link

You can make lines beginning with a space behave like a <pre> block by additionally using the <nowiki> tag.
On the other hand we could just have a rule to avoid HTML markup in general reserving its use exclusively for templates. This, combined with the template unification/simplification proposals, could simplify the rule book since we will not need more rules to govern the use of other HTML tags. James Eder 14:53, 18 September 2011 (EDT)
Ok with avoiding all unnecessary uses of <pre>, but there are cases where it has no substitutes atm, for example:
indented code blocks
  • bulleted code blocks
Maybe one solution could be to move Template:Bc to Template:BHc (where H means with Heading) and use Template:Bc as a replacement for <pre>.
About HTML markup, the wiki makes use of some floated divs somewhere, the Main Page is an example, so avoiding HTML tags completely should allow exceptions. Nonetheless we could indeed keep a whitelist of allowed tags and their uses.
-- Kynikos 06:26, 19 September 2011 (EDT)

Point to "authority" articles (i.e. de-duplication of efforts)

Before writing a specific procedure in an article, or describing something in particular, always think: is there already an article that treats this part in detail? If yes, link that article instead of duplicating it; if not, wonder: could this part be generalized and made useful also for other articles? If yes, write a new appropriate "authority" article for that and then link it in the article you were writing; if not, just go on with your original article.

For those who are a bit familiar with programming languages, this is the same as defining functions, classes, methods, structures and so on... You don't want to uselessly repeat code ;) Also for ease of maintenance.

The negative side of this is the possible loss of flexibility, and this is especially true when making templates: in these particular cases it's better to discuss with the community first.

Already described examples are #Package installation, #AUR package installation, #rc.conf arrays and to some extent, #Introductions: de-duplication of effort.

-- Kynikos 05:34, 7 June 2011 (EDT)

Also avoid duplicating guides of external projects which already have their own original documentation: the ArchWiki should talk about how to make things work in Arch Linux, nothing more. -- Kynikos 05:41, 8 June 2011 (EDT)

There's a risk that the linked site will go offline or will get abandoned & vandalized. -- Karol 06:03, 8 June 2011 (EDT)
And that's the positive side of duplicating efforts, a.k.a. reinventing the wheel; while it's true that some work seems "wasted", having multiple instances of the same "project" is as useful as competition in nature or economics: the healthiest/stronger/smarter/richer lives, the other one dies. Afterall, the Linux community is one of the best examples of multiplication of efforts.
Maybe the administrators will take a decision about this subject. -- Kynikos 10:36, 9 June 2011 (EDT)
How about a general suggestion that when creating new articles, create the "See Also" or "Resources" section first? Doing so naturally causes one to go look at what's already out there. It may even lead to the writer asking the question "Do we really need our own article for this?" Who knows, one might even discover the upstream has a wiki of its own which can be improved instead. Even if the documentation is not on a wiki, if the upstream documentation is broken or out of date then one really should ping the author about it (bug reports, patches, gentle nudging via email or mailing lists, etc). At any rate, I would hazard to say that almost all articles should link to upstream documentation. That effort alone might reduce some duplication of effort especially if the upstream is in good shape. James Eder 15:51, 30 June 2011 (EDT)
In theory yours could be a good idea, but in practice I think that this style guide will be mainly helpful for people fixing existing articles, not for users creating them. For example when creating new articles, users should also remember to categorize them, but that is done very rarely indeed. -- Kynikos 06:09, 5 July 2011 (EDT)

Configuration header

According to the Help:Editing guidelines, a general outline for an article should have a configuration header that follows the installation. Should this 'configuration' header also include the steps on how to run the software as well,(e.g. 'running somesoftware' + 'running somesoftware at startup') or should the 'running' steps be separate. In many cases, running the software is often a part of the setup or configuration part. I think it should be included in the configuration to keep the hiearchy more KISS. -- Roygbiv 10:12, 8 July 2011 (EDT)

I think this should be adapted to each article, I don't see a big advantage with standardizing it. About the hierarchy, I don't think that the less the headings, the better (i.e. KISSer): I believe that there shouldn't be unnecessary headings, but also the idea of trying to put systematically everything under the fewest possible headings can't be always the best solution. -- Kynikos 05:26, 9 July 2011 (EDT)


Does this mean we should remove sections like this one? -- Karol 20:21, 20 July 2011 (EDT)

I guess the thread should still be linked as a source: I think that reporting the sources for an article is good practice, but credits sections are not meaningful since an article is generally the product of the work of many. -- Kynikos 05:18, 21 July 2011 (EDT)
Yes, I think it should be morphed rather than removed. A "See also" section would do nicely, IMO. I guess this is really related to #Standard headings? James Eder 12:36, 21 July 2011 (EDT)

Direct links

I don't think it's about playing favorites, often it's a PITA to find the package if you're using just the keyword. It's true for both AUR and official packages. Wouldn't it be better to use a couple of direct links in such cases? -- Karol 21:03, 25 August 2011 (EDT)

Just modified the AUR template to return exact matches only. Not sure if there's a similar option for the official page... -- pointone 21:14, 25 August 2011 (EDT)
That was a super-speedy response, thanks. One can always use a regular link instead of a template if needed, so I consider it fixed. -- Karol 22:30, 25 August 2011 (EDT)

Templates don't play nice with article summary

ASP.NET with Apache shows template on top of the summary. Do we want to fix this or is it a "special case" as the articles shouldn't feature any templates of this kind (i.e. merge, delete, out of date etc.)? -- Karol 23:06, 25 August 2011 (EDT)

No need for a special case, this is much more easily handled with the rule "put article summary after block templates like requests". -- Kynikos 09:45, 26 August 2011 (EDT)
Ah, of course. Thanks a lot. -- Karol 10:08, 26 August 2011 (EDT)
I should have thought of it before, there's an easy fix for this, we just have to put Template:Codeline to the containing divs of all those block templates. -- Kynikos 05:13, 1 September 2011 (EDT)
I mean, I'm asking here for confirmation before doing the needed changes. -- Kynikos 05:16, 1 September 2011 (EDT)
I can only whine about templates, I can't really fix them, so +1 from me if you want to have a go at it ;P -- Karol 09:59, 1 September 2011 (EDT)
ATM I've edited Template:Box, which affects all derived templates like Note... If you think it works fine (see example in pacman), the style could be added to the protected request templates as well.
Would it be useful to add it to other templates like Cli, Command, File...? Note that also overflow:auto should solve the issue, and it's already used for Template:Bc, maybe it's a better solution?
-- Kynikos 12:21, 1 September 2011 (EDT)
Are similar changes in the works for Template:Message box used for merge, delete, etc? James Eder 17:33, 1 September 2011 (EDT)
Template:Message box is protected, only admins can edit it (honestly I don't really get the need for this protection thing, but that's another story ^^ ). -- Kynikos 19:06, 1 September 2011 (EDT)

Tip box in introduction overlaps with summary

In articles like pacman tips, notes, etc placed before the TOC overlap with the summary. The overlap is easily fixed by moving the article summary below the note, but that often looks awkward. I couldn't find any official guidance on this and I'm not sure these things usually belong there in the first place. If some guideline exists it could be clearer in Writing Article Introductions and Help:Style, thank you. --Emiralle 21:35, 31 August 2011 (EDT)

See above for a definitive solution. -- Kynikos 05:13, 1 September 2011 (EDT)

i18n links

Improve_Pacman_Performance or Archiso show French links in red, but there's a link to the external French wiki in 'In other languages' box - can we show the French link in i18n box in blue w/o creating a page that will just be used as a redirect? -- Karol 19:25, 1 September 2011 (EDT)

I don't think it's possible, AFAIK wiki templates can't execute conditional statements, and i18n can't be modified to always point to the external wiki for some languages, since it would need to translate the English title (and also would have the opposite problem, the link would always appear blue); I guess a redirect is the only way. -- Kynikos 04:48, 2 September 2011 (EDT)

Should we add links to external wikis just to the English article or to every one: Arch_User_Repository_(Српски) has the link to the French wiki, Thestinger also started adding such links to non-English articles. -- Karol 19:25, 1 September 2011 (EDT)

Of course adding external links to all articles would be the ideal situation, but it would take quite a lot of bravery, to check every translation of every article... Maybe it would be the perfect work for a learned bot. -- Kynikos 04:48, 2 September 2011 (EDT)

Category:Website Resources

What is the purpose of Category:Website Resources? -- Kynikos 09:18, 19 September 2011 (EDT)


Is Template:Ic going to replace also Template:Filename? -- Kynikos 09:18, 19 September 2011 (EDT)

My opinion: I like current Template:Filename usage as it is currently. I would, however, like to see other templates and other HTML tags migrated to Template:Ic and Template:Bc. That is, of course, once they are no longer "in development" (nudge, nudge). James Eder 20:37, 19 September 2011 (EDT)
Eheh those templates are in development because they're waiting to be enforced together with this very article, I also prepared some sort of a migration procedure some time ago in User:Kynikos/Random formatting ideas#Upgrade_procedures although it'd need heavy upgrading itself.
Waiting for more responses about Template:Filename, default is not replacing it. I am a bit undecided on this, because replacing it would go in the direction of simplicity, and it would be coherent with the decision not to distinguish between cli and file text in block code templates; on the other hand I've never been very convinced by that decision, so that's why I'm asking for opinions.
-- Kynikos 05:52, 20 September 2011 (EDT)
Can summarize what we do and do not have a consensus on here? The migration process seems to be fairly straight forward it just needs to be said which templates we are sure about. Is Template:Filename the only one left undecided? James Eder 13:06, 20 September 2011 (EDT)
There has never been an official discussion on this, so I'm creating #Migration to new code templates. -- Kynikos 12:50, 21 September 2011 (EDT)

Archive discussions?

[moved from ArchWiki:Reports -- Kynikos] I'd like to archive the old talk page sections rather than deleting them. I know there has been an inclination toward deletion in order to maintain a up-to-date wiki, but I'd prefer the Wikipedia standards. If this has been discussed elsewhere on ArchWiki, I'd love to discuss it there. However, inevitably, it's just a preference, and I'm not married to the idea. ~ Filam 21:25, 19 September 2011 (EDT)

I don't know, the only example I'm aware of here is ArchWiki:Reports/Archive, but also that one has a clean-up procedure. Discussions are deleted assuming that the idea that was discussed has either been implemented in the article or discarded completely, so I'm not sure if archiving would be so useful, but let's wait for more opinions. -- Kynikos 06:06, 20 September 2011 (EDT)
I'm in favor of deleting, you can strike out the headings and leave them for a while, then batch-remove them with a proper summary - it will make it easier to find them in wiki history if needed. -- Karol 08:11, 20 September 2011 (EDT)

Migration to new Code formatting templates

Months have passed since the initial proposal to restyle the Code formatting templates, references can be found here:

The new templates are Template:Ic for inline code, and Template:Bc for block code.

A possible migration strategy could be the following:

  • Cli -> space-initial lines or <pre>
  • Codeline -> Ic
  • Command -> space-initial lines or <pre>
  • File -> Bc
  • Filename -> Ic (or keep Filename? see also #Template:Filename)
  • Kernel -> Bc
  • Cursor -> deprecate?

As discussed initially on #Do not use <pre> for one-liners, we could also copy the current Template:Bc to Template:BHc, and restyle Template:Bc to look like <pre>, thus deprecating the use of <pre>.

Another related discussion: #Prepare examples of both simple and advanced use of the (new) wiki templates & formating.

Please share your ideas. -- Kynikos 12:50, 21 September 2011 (EDT)

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)

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)
  • 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)
  • [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)
  • [add more advantages...]