 |
del.icio.us |
 |
Digg |
 |
Furl |
 |
|
 |
Rojo |
| Add to OnlyWire |
 |
This is an essay, a page containing the advice or opinions of one or more Wikipedia contributors. Essays may represent widespread norms or minority viewpoints, and they may be heeded or not based upon your judgement and discretion. |
 |
This page in a nutshell: Avoid cryptic language. Try to keep your use of abbreviations down when talking with human beings. |
Page title translation: What The Fuck? Oh My God! Too Many Damn Three Letter Acronyms. ARRRGGGHHH!
Basically, when WP:EDIANS CITE pages in the PRJ NS, they often refer TO them using CUTS like "BEANS", "BALLS", and "NFCC". While these ABB are GREAT for RDRing to a particular page you USE often, it's probably a BAD idea to make a POINT of using these TLAs in daily TALK, lest your discussion end UP AS NONSENSE like the TITLE of this page.
Translation:
When Wikipedians refer to pages in the Wikipedia namespace, they often use shortcuts like "WP:BEANS", "WP:BALLS", and "WP:NFCC". While these are quick jargon, and get you quickly to a particular page you use often, it's probably a bad idea to habitually use these acronyms in daily conversation, lest your discussion end up as nonsensical as the title of this page.
Contents |
Avoid unnecessary jargon
People use jargon because it's useful for efficiency, especially when doing hundreds of similar laborious but important edits (e.g. vandalism patrol) — but jargon still directly excludes people, even when used with the best of intentions. It can take a conscious effort to avoid it. Don't Bite The Newbies.
If you use abbreviations all the time, you risk neglecting what the expansion actually is and thus saying something that isn't what you actually mean.
- e.g. Many editors say "WP:POINT" as an admonition for behaviour that ignores a process; this neglects the actual title of the guideline in question, which refers to following a process in a way one does not personally advocate with the intent to demonstrate that the process is ridiculous.
Avoid projecting elitism
Newer editors will often encounter the first heavy use of these abbreviations in the talk pages of articles, Articles for Deletion discussions, or other administrative areas of Wikipedia. To keep the community open and inviting to newcomers, editors should avoid the use of cryptic language and acronyms, as it projects a sense of elitism that is likely to alienate newer editors.
For example, when indicating the reasons that an article should be deleted, the following is hostile to newer members:
Nominated for deletion, WP:NOR, WP:N, WP:V
Instead of listing an alpha-bet soup of codes, the following is better:
Nominated for deletion as original research and lack of notability; in addition, it does not appear to be possible to verify the accuracy of the sources, as the article contains only references that are contained in unpublished manuscripts.
It is longer, but far more understandable, and contains a little context that allows someone to understand particular reasons why a policy might apply. While it may be obvious to you why a given policy applies, it may not be to others--even very experienced editors!
Moral of the story
Always use a proper name for a Wikipedia namespace page when discussing it. If you find you are getting sore wrists and fingers from all the typing, try to simplify or summarise the pages you are referring to, so that in future you only need to refer to a single link. ;-)
- or
This is an encyclopedia, not text messaging.
Offline users suffer the most
Consider, for example, offline users. Offline users go nuts as they have to wait until they return home to connect to the network to find out what the snooty abbreviations mean in the article they are reading offline.
They download interesting articles on to their PDA, go on a camping trip, only to find them full of esoteric abbreviations, with not even the real article's name expanded in the HTML href (wasting another HTTP request tool). They must wait until next week when back in town to find out what they mean.
Just 0.1% more bytes and the articles could be self-contained.
Moral of the story #2: make self-contained articles!
