:::Ah ok, then formatting in this case should be coherent with [[#Pseudo-variables]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:07, 6 June 2013 (UTC)

:::Ah ok, then formatting in this case should be coherent with [[#Pseudo-variables]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:07, 6 June 2013 (UTC)

+

+

===GUI/TUI text===

+

For example menu entries.

+

+

* "Then, select ''Boot Arch Linux'' from the menu and press {{ic|Enter}} in order to begin with the installation" ([[Beginners' Guide]])

+

* "When using Gparted, selecting the option to create a new partition table gives an ''msdos'' partition table by default. If you are intending to follow the advice to create a GPT partition table then you need to choose ''Advanced'' and then select ''gpt'' from the drop-down menu." ([[Beginners' Guide]])

+

* "Type {{ic|yes}} and choose ''Quit'' (or press {{ic|Q}}) to exit without making any more changes." ([[Beginners' Guide]])

General indications

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)

Bold

Italic

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)

Underlining

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)

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

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)

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)

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)

Single file names

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.

"This article deals with so-called core utilities on a GNU/Linux system, such as less, ls, and grep." (Core Utilities)

Note that this rule applies to executables when they represent the application/file itself, not when used in #CLI lines (remember to fix this link). In particular pay attention to executables that are usually run without any arguments:

Name of application in the beginning of application-related article

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 https://www.archlinux.org/ 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)

Inline templates

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)

GUI/TUI text

For example menu entries.

"Then, select Boot Arch Linux from the menu and press Enter in order to begin with the installation" (Beginners' Guide)

"When using Gparted, selecting the option to create a new partition table gives an msdos partition table by default. If you are intending to follow the advice to create a GPT partition table then you need to choose Advanced and then select gpt from the drop-down menu." (Beginners' Guide)

"Type yes and choose Quit (or press Q) to exit without making any more changes." (Beginners' Guide)

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.

Yes, but a warning does not exclude a not -- Flu (talk) 10:57, 8 June 2013 (UTC)

So, a general rule could be to use italic for words whose importance in giving the meaning to a sentence would not be recognized otherwise; usually they would be pronounced in a stressed way if reading out loud:

I'd like to follow Wikipedia on this topic, and avoid italic for quotations: in general, I'd refer to Wikipedia's guidelines, so use quote marks for inline quotations, and <blockquote> or : (we'd better choose only one form here) for block quotes, without italic-izing them.