OLPC:Style guide

This article is a stub. You can help the OLPC project by expanding it.

Welcome to the OLPC Wiki style guide. This is here to keep people from creating pages with strange wikisemantics and titles and categorizations that don't naturally help other wiki users find them. Or lead to edit wars that continue across centuries.

Article naming

Starting a new article

• Always check for alternative capitalizations - if you're starting Content Projects, check for Content projects first.
• Avoid capitalizing page titles unless a necessary proper noun. Use Content projects, not Content Projects.

Subpages

In general, subpages are to be avoided -- better to use a descriptive name which can be read out without a 'slash' somewhere in it. However, there are exceptions:

• Archives of a page/talk page
• Dated versions of the same page ... though these should usually be without subpages as well, unless they are dated versions of large subsites, which only link to one another. For instance, if we were to make a "2006" version of Localization/www.laptop.org, that might go under Localization/2006/www.laptop.org... since there are many other pages that go along with it.

Preparing for the future

If you are starting a specific type of page and know that you will need to make general versions later, that's fine -- use the most generic name that is not already taken. likewise, if you are starting the "August 2007" version of a page, leave it at the general name until you have more than one instance, at which point you can start to move to archival page titles. This just helps ensure that any specific page-name is part of an ecology that includes more generic page names and overviews of the abstract topic at hand.

Links, classification, and structure

Links to other articles

Links can be listed in full, in which case you should replace any underscores in the link with a space. For instance, Style guide should not have an underscore -- even though Style_guide links to the same page, the underscore is ugly.

Similarly, avoid running words together in CamelCase unless you are referring to a proper noun such as MediaWiki. This makes it easier to link words used normally in a sentence.

Headers

• do NOT use H1 headers within a page (i.e., a header with a single equals on each side). Start your hierarchy with H2 headers within the body of the wiki article.

H1 headers should be reserved for the page title on a page; any further H1's should indicate the inclusion of an entire other page. Imagine what happens when you transclude one page at the end of another: this should make sense within a Table of Contents if you add an H1 header before it.

Categorization

Every page should belong to a category (multiple categorization is possible) so when creating one, try to find a good one.

Writing

Write for translation

See also Guidelines for writing for eventual translation for a more detailed description of guidelines.

Keep sentences simple:

• Avoid idioms and extended metaphors. Where metaphors are particularly useful, try to use one that is universal and has no double-meanings.
• Avoid subclauses or long sentences.
• Avoid long strings of adjectives or nouns.
• Convert sentences in unusual tenses into ones in simple tenses with extra clarifying notes.

Keep words clear and unique

• Avoid words with ambiguous meanings.
• Long words with clear roots can be better than short words that are obscure or have many connotations

Using advanced features

Templates

Are special pages intended to be transcluded in other pages producing some result based on the parameters provided or extracted from the including page. A template that just transcludes static text is not a template and should be treated as normal page. There's the Template:Sandbox to try new ideas on templates.

Templates should be tagged with the <noinclude>[[Category:Template]]</noinclude> or one of its subcategories.

Page transclusion

The composing of an article based on other pages is a very powerful idea but that can quickly get out of hand as interdependencies develop (not to mention the complication for future editors to actually find the right page to edit). Still, it's a powerful (and sometimes complicated) way to reuse context in several places.

Visual design of pages

Some of the principles in the HIG apply across the board. For instance, walter is unhappy with the insertion of navigational elements (or is it just visual attractions?) in the middle of a page; see template talk:support-nav for a recent discussion.

External links

• From useit.com, ca. 2002