PC-BSD Wiki talk:Style Guidelines

From PC-BSD Wiki
Revision as of 23:16, 1 August 2012 by Tigersharke (Talk | contribs)

Jump to: navigation, search

This page may eventually get so large that it might need to be refined. It should eventually be used to create some examples, like the stub page, to partially replace some of the content here.

Perhaps a specialized template that could be called, which automatically highlights within its content, the portions referenced as examples. In this way, the example page could be extremely inclusive with built-in context to help clarify. This is starting to sound like a very cool idea. :)

Contents

needed markup for lists

Once ("official") again:

Style Guidelines (of our PC-BSD Wiki) are telling for lists, that we need a hard enter to ensure that the PDF and EPUB versions format correctly.

Does this count only for "unordered" lists? A change for a numbered list does not include hard enters.

Does anyone can check the result of the PDF and EPUB versions for it? Probably it does not format correctly, because they are also items (like for normal bullet), or not?

Maybe a <br> at the end of every (without the last) item would help (enough). (BTW: I did such a change preliminary.)

Here my example (as an offer) for the section Bullets:

To ensure that the PDF and EPUB versions format correctly, use a additional [[wikipedia:Help:Wiki markup#Line breaks|<code><br></code>]] between the items in a list.

== Bullets ==

There are two types of bullets in use:
# A bulleted list which begins uppercase. Whether or not it ends in punctuation depends upon the size of the list. For example:<br>
#* the [[What's New in 9.1]] list uses sentences to describe the features so ends in a period. Use this type of list when the list includes a description large enough to warrant at least one sentence.<br>
#* the [[Minimum Hardware Requirements]] list uses few words per item. Since the individual items do not warrant a sentence, this type of list does not end in a period.<br>
# A  bulleted list which begins with bolded text (typically the name of a menu item). The bolded section is capitalized to match the name of the menu item and followed by a colon (:). The sentence following the colon begins lowercase and should be worded so that the bolded item is the beginning of the sentence. An example is:<br>
#: '''Size on Disk:''' indicates the amount of space being used by the jail.<br>
#:: In this example, the menu item appears as "Size on Disk" (mix of upper/lowercase), "indicates" is lowercase and is worded so that it reads as one sentence (including the name of the menu item). Because it is a sentence, it ends with a period.

"in terms of collegiality"

-- Rg 11:55, 12 July 2012 (PDT)

I think I would be open to most any formatting of the bullets/lists as long as it can be consistent among variations and for the range of formats (html, epub, pdf, etc) and whatever is easiest/simplest and/or does not add a significant amount of work/typing. I generally do not deal with conversion to epub or pdf, so I cannot really offer any suggestions for that, and my methods may differ compared to how others might convert to those formats.

--Tigersharke 01:19, 13 July 2012 (PDT)

After more thought and comparison, I chose to swap your bullets section as you formatted it, into the text of the guidelines. (I agree with the format and use of it)

--Tigersharke 02:46, 18 July 2012 (PDT)

Overall size of document

The style guidelines page is good so far, and helpful with its completeness, but I think it will better serve if it were more brief. This can be achieved by transferring the examples to a page that would include context for all such examples. Also, it would allow for multiple examples to be shown while the hinted example could be highlighted. This would be possible via 2-piece wiki page. a simple page that sources a template perhaps, with the call to the template at each link to the example. Each example in this contextual example page would be numbered so that calling the page link would cause the specific example highlighting. Of course this is all still a really cool concept which has not been fully explored as yet- but doesn't it sound amazing?!

--Tigersharke 02:48, 14 July 2012 (PDT)

Headings vs CSS

This is the one part of our style guidelines that seems abused the most, with regard to how things probably should be done, versus how they have been done. I believe there is some issue of final appearance via heading markup that is preferred over the proper way of using headers. Due to this, if the actual desired results might be defined, then the wiki css can be adjusted to match, rather than skipping header levels or other such divergence. We may be stuck enforcing a non-standard heading formula if the CSS format is not determined or not switched in a timely manner.

--Tigersharke 02:59, 18 July 2012 (PDT)

Representation of dates and times

Maybe we should doing also wikipedia:ISO 8601 usage? :-/

--Rg 08:54, 1 August 2012 (PDT)

I think the built-in {{#dateformat:01 May 2012}} is about the best we can do, until the wiki software itself better conforms to ISO 8601. This was added to the style guidelines.

--Tigersharke 23:16, 1 August 2012 (PDT)