Help talk:Style/Formatting and punctuation

From ArchWiki
< Help talk:Style
Revision as of 03:20, 26 June 2013 by Kynikos (talk | contribs) (Formatting cases: fix)
Jump to: navigation, search

General indications

[Split from a longer discussion: [1]. -- Kynikos (talk) 15:23, 5 June 2013 (UTC)]

I am personally against any formatting at all, at least where it can be avoided. IMHO, if we want formatting in articles to be meaningful and helpful for readers, it is necessary to completely deprecate it's usage except limited list of well-defined cases. Such lists would obviously tend to change, but at least this would help to prevent counterintuitiveness and inconsistency. --AlexanderR 20:45, 3 February 2012 (EST)

I think what AlexanderR wrote here is very important: the style rules that will derive from this talk page will have to be a white list of (very) specific cases that require formatting, like in "all text is to be left without formatting except for the following cases: ...". -- Kynikos (talk) 13:26, 4 June 2013 (UTC)
We could also mention Wikipedia:Manual of Style in the guide and only integrate it (or override, if really necessary) where needed. -- Kynikos (talk) 07:03, 6 June 2013 (UTC)



With respect to this Wiki specificity (and taking into account various precedents) I propose to limit usage of bold text to: --AlexanderR 19:44, 31 January 2012 (EST)



I already noticed two kinds of italic usage in this Wiki, conventional enough to be proposed for this role (I am so lazy.. please add examples yourself if you want): --AlexanderR 19:44, 31 January 2012 (EST)



As far as I know underlining is used relatively rarely in this Wiki. The only use case I can imagine is using in place of bold (e.g. for highlighting single words and sentences without pulling them out of context). If we decide to deprecate direct usage of bold text in order to fully utilize it for technical purposes, such replacement would be suitable. --AlexanderR 20:45, 3 February 2012 (EST)

Following Wikipedia:Manual of Style/Text formatting#How not to apply emphasis I would deprecate any use of underlining. -- Kynikos (talk) 07:33, 6 June 2013 (UTC)

Quoting and double quoting

Quoting belongs to punctuation rather than formatting, so there is nothing to discuss. --AlexanderR 20:45, 3 February 2012 (EST)

Now the discussion also includes punctuation :) -- Kynikos (talk) 11:51, 4 June 2013 (UTC)

Alternative approach

We could define our own basic (or simple, following Arch's philosophy) rules for italics and bold, and derive all the use cases from them. Citing AlexanderR in #Inline templates, I would find it quite natural to use bold to "attract additional users attention" and italic to "offset text from its surrounding content".

Once these two cases are defined, all the specific uses should come quite naturally, for example #Executables names (as executables in file system, not in command line) and #Pseudo-variables would be in italic, #"not" and #Important part of file/command line contents would be in bold. Under these simple rules, I would even be in favour of using italic for #Single file names.

In this case I would reserve the use of Template:ic only for:

  • Complete commands, e.g. "run grep Ignore /etc/pacman.conf using the grep utility"
  • Full file paths
  • Content that can be read or written on a file, e.g. "add bind '"\e[A": history-search-backward' to your .bashrc file" or "check that the GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub is set to "quiet splash", thus making the whole line of the grub file be GRUB_CMDLINE_LINUX_DEFAULT="quiet splash""
  • In general when it can make sense to copy-paste the ic'ed text in a terminal or a text editor (i.e. when there can be a realistic reason for doing it)
  • Keyboard keys, see Help talk:Style/Migration to new Code formatting templates#Template:Keypress

Note however that basically I'm brainstorming, there are probably many aspects that I've overlooked with this reasoning, so please go on and comment!

(EDIT:Comment only on the two "basic" definitions defined in the first paragraph; the rest of the post is only used to give an idea of what the consequences would be. To comment each specific case, just reply to one of the sections below or create a new one)

-- Kynikos (talk) 07:31, 6 June 2013 (UTC) (Last edit: 14:38, 6 June 2013 (UTC))

Any comments on this? Anybody else with some opinion on these issues? The problem is that it's difficult to make decisions here since I and Flu do not agree on everything, so any additional point of view will be highly appreciated ^^ -- Kynikos (talk) 13:17, 10 June 2013 (UTC)

Formatting cases

Merge-arrows-2.pngThis article or section is a candidate for merging with User:Kynikos/Formatting and Punctuation.Merge-arrows-2.png

Notes: Moving here Kynikos' comprehensive rule proposal. -- Kynikos (talk) (Discuss in Help talk:Style/Formatting and punctuation#)

Technical terms

I suggest using italic:

  • "you are encouraged to type man command to read the man page of any command" (Beginners' Guide)
  • "This article deals with so-called core utilities on a GNU/Linux system" (Core Utilities)
  • "Primary partitions can be bootable and are limited to four partitions per disk or RAID volume." (Partitioning)
  • "This is already a separate partition by default, by virtue of being mounted as tmpfs by systemd." (Partitioning)

Except for all-caps terms (usually acronyms), unless they are part of an italic-ized list of technical terms (formatting consistency prevails):

  • "you have to press a key (usually Delete, F1, F2, F11 or F12) during the POST (Power On Self-Test) phase" (Beginners' Guide)
  • "Please choose the UTF-8 entry." (Beginners' Guide) (could be thought of as part of a line in /etc/locale.gen and grouped in #(M) File content)

-- Kynikos (talk) 03:20, 26 June 2013 (UTC)

Single file names

(Highly questionable)

search for loop.ko in /lib/modules/kernel_release

--AlexanderR 19:44, 31 January 2012 (EST)

It seems I raised the problem again:
I second AlexanderR choices, also the first point (between fstab and fstab the latter is better-looking), plus the package name (once Pkg template has been used the first time). I bring to bear witness Core_Utilities article which is quiet good-looking, I think, also using lynx. -- Flu (talk) 16:10, 2 June 2013 (UTC)
I'm against bold in this case, consistency is more important than aesthetics, so we should use the same formatting for both full-path file names and short (single) file names. I'm in favour of using Template:ic for filesystem paths and file names.
search for loop.ko in /lib/modules/kernel_release
-- Kynikos (talk) 05:57, 6 June 2013 (UTC)
good point, changed my mind, +1 -- Flu (talk) 21:07, 6 June 2013 (UTC)

Executables names (as executables in file system, not in command line)

javaws, which is in icedtea-web-java7

Template:Box YELLOW

--AlexanderR 19:44, 31 January 2012 (EST)

An interesting case from Installation Guide:
  • Uncomment the selected locale in /etc/locale.gen and generate it with locale-gen
I guess technically locale-gen would stay formatted that way, since it would be the same as writing:
  • Uncomment the selected locale in /etc/locale.gen and generate it executing locale-gen
If however for instance the sentence changed very slightly to:
  • Uncomment the selected locale in /etc/locale.gen and generate it with the locale-gen utility
Following AlexanderR's way it should become:
  • Uncomment the selected locale in /etc/locale.gen and generate it with the locale-gen utility
And with #Alternative approach it should become:
  • Uncomment the selected locale in /etc/locale.gen and generate it with the locale-gen utility
-- Kynikos (talk) 14:32, 10 June 2013 (UTC)

Kernel module names

ensure that radeonfb is blacklisted

--AlexanderR 19:44, 31 January 2012 (EST)

Important part of file/command line contents

root=/dev/sda6 ro 5 radeon.modeset=1 vga=current logo.nologo quiet splash

--AlexanderR 19:44, 31 January 2012 (EST)

This one can be acceptable. -- Kynikos 17:58, 3 February 2012 (EST)

Name of application in the beginning of application-related article

Foo is the most popular Linux alternative to Wikipedia:Bar.

--AlexanderR 19:44, 31 January 2012 (EST)

I don't know, usually the name of the application is also the title of the article, so this rule could just add bloat for nothing. I'd recommend to use the first encounter of the app name as an anchor for a link to the official website instead. If there's nothing to link, leave it in normal weight. -- Kynikos 17:58, 3 February 2012 (EST)
>> so this rule could just add bloat for nothing
Maybe, but for some reason cited HTML5 developers, authors of many articles in this Wiki and even webmaster believe this to be "conventional typographic presentation". This, however, does not oblige us to support such case of usage here.
>> I'd recommend to use the first encounter of the app name as an anchor for a link to the official website instead.
This is neither consistent (there is often nothing to link) nor intuitive – user can not see link destination without hovering cursor over it. As I said in discussion on "See also visibility", links to Wikipedia article(s), application home page(s), application project(s) on code hostings etc. together with reliable summary are the only reasonable content for article summary template and should probably be placed in that single predefined place. --AlexanderR 20:45, 3 February 2012 (EST)


I don't know if we should use bold or what else when using pseudo-variables like:

# modprobe module_name
# modprobe module_name
# modprobe <module_name>
# modprobe [MODULE_NAME]

(from Kernel Modules). -- Kynikos 17:58, 3 February 2012 (EST)

This conflicts with "important part of file/command line contents" part. As I said below, italic seems to be more appropriate.
Probably worse idea than just italic: Another proposal –
# modprobe <module_name>
This way pseudo-variables become highlighted and offset from surrounding text at the same time but in different way than "important part". --AlexanderR 20:45, 3 February 2012 (EST)
I prefer:
# modprobe module_name
-- Flu (talk) 15:20, 2 June 2013 (UTC)
+1 (plain italic). -- Kynikos (talk) 06:08, 6 June 2013 (UTC)

Inline templates

(IMHO, those with italic formatting look much better than ones with bold formatting):

--AlexanderR 19:44, 31 January 2012 (EST)

I don't understand, you'd use always italic inside Template:ic regardless of the content? In that case I don't even like it aesthetically :) -- Kynikos 17:58, 3 February 2012 (EST)
This is exactly what you name "pseudo-variables" (your wording was better than mine, lets use it). Using bold in this case conflicts with "important part of file/command line contents" part; italic would also be more intuitive: we want to offset text from its surrounding content rather than attract additional users attention. --AlexanderR 20:45, 3 February 2012 (EST)
Ah ok, then formatting in this case should be coherent with #Pseudo-variables. -- Kynikos (talk) 07:07, 6 June 2013 (UTC)


not bold when it is worth -- Flu (talk) 15:20, 2 June 2013 (UTC)

I would use italics in this case, see also Wikipedia:MOS:text_formatting#Contraindications and Wikipedia:MOS:text_formatting#Emphasis.
It would also be great if we could find the right words to define "worth".
-- Kynikos (talk) 06:12, 6 June 2013 (UTC)
Attempt 1: it is worth when it may lead a user to a dangerous or inefficient choice.
I do not like italic by the way, it is not that evident. -- Flu (talk) 21:15, 6 June 2013 (UTC)
So would you see these special nots as kind of a super-compact Template:Warning? (as defined in Help:Style#Notes, Warnings, Tips)
About bold vs italic, I'd support bold if there was agreement over #Alternative approach: I want to find a solid basic reference from which derive all our text formatting rules, instead of deciding case by case without any kind of global vision of the problem; in this section I proposed to base our rules on Wikipedia's style rules, but now I tend to prefer the definitions that I've exposed in #Alternative approach.
-- Kynikos (talk) 14:43, 7 June 2013 (UTC)
Yes, but a warning does not exclude a not -- Flu (talk) 10:57, 8 June 2013 (UTC)

Cites from external sources

All your data belongs to us – Google

--AlexanderR 19:44, 31 January 2012 (EST)

...or "All your data belongs to us" (w/ quotes)? (see e.g. Beginners'_Guide#The_Arch_Way) -- Kynikos 17:58, 3 February 2012 (EST)
This is matter of punctuation, not formatting. --AlexanderR 20:45, 3 February 2012 (EST)
Both ways seem incoherent with Wikipedia:MOSQUOTE#Italics and quotations. -- Kynikos (talk) 07:00, 6 June 2013 (UTC)