Difference between revisions of "Help talk:Style/Formatting and punctuation"

From ArchWiki
Jump to: navigation, search
(Proposed change to repository naming convention: reply to Kynikos)
(Proposed change to repository naming convention: re)
Line 59: Line 59:
 
::::pacman could be patched to display square brackets around repository names in its output, but I don't know if Allan or the other pacman developers would want that. I don't feel strongly either way about pacman's output. I can send an RFC to ''pacman-dev''.
 
::::pacman could be patched to display square brackets around repository names in its output, but I don't know if Allan or the other pacman developers would want that. I don't feel strongly either way about pacman's output. I can send an RFC to ''pacman-dev''.
 
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 21:29, 8 December 2013 (UTC)
 
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 21:29, 8 December 2013 (UTC)
 +
 +
:::::Well, until now I haven't stated my purely aesthetic preference (ignoring any technical issues), and honestly it's still oriented towards the version without brackets.
 +
:::::But really, how often do you encounter repository names on the wiki? Mentioning the official repositories when installing packages is [[Help:Style#Official packages|taboo]], and when mentioning unofficial repositories, most often they will [[Help:Style#Unofficial repositories|need a link]], which IMO is already highlighted enough without the need for any brackets.
 +
:::::However we may prepare a poll, like it's been done for other style issues in the past, which has always proved to be the best way to find shared solutions. The choices should be sets of styles for repos in plain text, links and section headings, remembering that article titles cannot have square brackets (MediaWiki limitation).
 +
:::::About the possibility of an "allowed" style, of course it can't happen since it would defeat the purpose of a style rule in the first place, which is meant to ''unify'' the looks of articles :)
 +
:::::About patching pacman's output, I wouldn't support the request, but, well, if the Devs accepted - or rejected - it, it would certainly be a strong argument for this discussion.
 +
:::::-- [[User:Kynikos.bot|Kynikos.bot]] ([[User talk:Kynikos.bot|talk]]) 12:10, 9 December 2013 (UTC)

Revision as of 12:10, 9 December 2013

Pseudo-variables

I'm pretty sure that I have already mentioned this before, but apparently with no result: pseudo-variables in the current form cannot contain spaces as it somewhat conflicts with Bash syntax (i.e. it can be misunderstood as multiple arguments instead of just one). Take [1] vs. [2] as an example to see what I mean. Please add the rule/warning directly to Help:Style/Formatting_and_Punctuation#Pseudo-variables_in_file.2Fcommand_line_contents.

While we're at it, I think we should also agree on unified style for pseudo-variables, CamelCase or underscore_style (or something different). I think that underscores are used more frequently in Bash.

-- Lahwaacz (talk) 23:08, 3 December 2013 (UTC)

I don't remember talking about this instead :P Of course spaces are bad, I simply forgot to fix that variable ^^ The reminder about spaces is added now.
About style, I'm not sure if we need a unified one, I think the style of pseudo-variables should match the style that is most commonly used by the actual values that the variable can assume.
-- Kynikos (talk) 03:17, 4 December 2013 (UTC)
I've fixed this minor typo: [3]. I was quite surprised that I could edit the page, perhaps it should be protected like Help:Style?
Pseudo-variables on ArchWiki are mostly used in shell commands, but it is possible to use them elsewhere (e.g. some other programming language). You are right that specific style is too strict to cover all cases, some strange capitalization might indeed sometimes make sense. I'm fine with the current recommendation to use underscores instead of spaces.
(Sorry for referring to non-existent discussion, it's just that I've seen this problem several times already and never got the time to report it. This was just a final spark I guess...)
-- Lahwaacz (talk) 07:23, 4 December 2013 (UTC)
Yep, in most cases the editor will naturally choose the most proper style, the biggest problem is the use of characters like <>, which is already handled by the style rule.
Help:Style was protected after an edit war a while ago, we can leave this page unprotected for now, unless something bad happens here too.
(Don't worry, it could be me to have forgotten about a previous mention of this issue :D )
I guess I can close this one. -- Kynikos (talk) 09:49, 5 December 2013 (UTC)

Proposed change to repository naming convention

Regarding Help:Style/Formatting_and_Punctuation#Repository_names, I am proposing that the style guide should recommend using square brackets around repository names.

It is a de facto standard in the Arch community to enclose repository names in square brackets, so I feel it would be appropriate to officially adopt this style in the style guide.

Current example:

  • If you enable testing, you must also enable community-testing.

Proposed example:

  • If you enable [testing], you must also enable [community-testing].

-- Jstjohn (talk) 00:24, 5 December 2013 (UTC)

+1, also note that Help:Style#Official_packages (last point) should be updated to whatever version we agree on. -- Lahwaacz (talk) 07:23, 5 December 2013 (UTC)
True that brackets are a de-facto standard, however it's also true that they create problems with wiki links, which is one of the main reasons why they were discarded. See for example the intricacy of [[multilib|&#91;multilib&#93;]] (from [4], now fixed) or [[#.5Bcommunity.5D|[community]]] in the intro of Arch User Repository.
If we recommended using brackets, what would we do when used in section headings? See for example Unofficial User Repositories. Or article titles? E.g. community. Maybe we could recommend to use them only with plain body text (no titles, headings, links...)? Or does it sound too complicated? It does sound complicated to me, however let's see what's your position over these issues ^^
-- Kynikos (talk) 10:07, 5 December 2013 (UTC)
Oops, I didn't recall this one in the morning as I was in a hurry... Links should definitely be kept simple, i.e. without brackets.
I don't like brackets in section headings either, both aesthetically and technically. For article titles, is that even possible?
I just realized deeper connection: square brackets in pacman.conf are used to start new section and the repository name is inside the brackets ([options] is special, no repo can have name "options"). pacman also does not show brackets in its output.
-- Lahwaacz (talk) 15:41, 5 December 2013 (UTC)
I've just added an example to the rule and updated Official Repositories, which now looks cleaner to me. I've also checked Official Repositories's backlinks for any broken fragments. -- Kynikos (talk) 04:06, 7 December 2013 (UTC)
Out of curiosity, why have you used bold in Official_Repositories#Historical_background? Is it just a typo or is there a pattern I did not recognize? -- Lahwaacz (talk) 07:17, 7 December 2013 (UTC)
Well, what happened there is that before my edit the current repos were already bolded, so that inspired me to apply Help:Style/Formatting_and_Punctuation#First_instances to the first relevant mention of each historical repo (that's the intended pattern); however on a second look the current repos have their proper section in the article, and that's a conflict with the first-instance rule, unless we justify it with Help:Style/Formatting_and_Punctuation#Name.2Fterm_lists. In the latter case, maybe the current repos could be highligted with links to their sections instead. -- Kynikos (talk) 02:56, 8 December 2013 (UTC)
Italicizing repository names looks much better than bolding them, but I do prefer the square brackets wrapped around them. Although, I'm not sure how much of that is an unconscious resistance to change/something different. Maybe if I saw more frequent use of repository names in italics or bold, I wouldn't mind it as much. *shrugs*
What about creating Template:Repository or Template:Repo (for less typing)? This would allow us to change the style around repositories with ease. For example, {{Repository|extra}} would result in extra or [extra], depending on what we choose. If done with CSS, I believe this would eliminate the issue with wiki links (e.g. using .repository:before { content: "["; } .repository:after { content: "]"; }).
-- Jstjohn (talk) 21:41, 8 December 2013 (UTC)
I, too, forgot about the issue with wiki links, but if possible, I would still really like to make square brackets part of the officially-approved style (or at the least, part of an allowed style).
pacman could be patched to display square brackets around repository names in its output, but I don't know if Allan or the other pacman developers would want that. I don't feel strongly either way about pacman's output. I can send an RFC to pacman-dev.
-- Jstjohn (talk) 21:29, 8 December 2013 (UTC)
Well, until now I haven't stated my purely aesthetic preference (ignoring any technical issues), and honestly it's still oriented towards the version without brackets.
But really, how often do you encounter repository names on the wiki? Mentioning the official repositories when installing packages is taboo, and when mentioning unofficial repositories, most often they will need a link, which IMO is already highlighted enough without the need for any brackets.
However we may prepare a poll, like it's been done for other style issues in the past, which has always proved to be the best way to find shared solutions. The choices should be sets of styles for repos in plain text, links and section headings, remembering that article titles cannot have square brackets (MediaWiki limitation).
About the possibility of an "allowed" style, of course it can't happen since it would defeat the purpose of a style rule in the first place, which is meant to unify the looks of articles :)
About patching pacman's output, I wouldn't support the request, but, well, if the Devs accepted - or rejected - it, it would certainly be a strong argument for this discussion.
-- Kynikos.bot (talk) 12:10, 9 December 2013 (UTC)