User:Omegatron/old user page

Wikipedia:Babel

enThis user is a native speaker of the English language.

fr-1Cet utilisateur peut contribuer avec un niveau élémentaire de français.

Search user languages

My wikistress level

About this Wikipedian

I am an audio electronics engineer and musician. I love Wikipedia... a little too much.

I never claimed to know everything, but sometimes I'll act like I do. If it makes you nervous and gets you to challenge your assumptions, it's working.

I've avoided putting braggy crap on this page, but, if it saves time and helps my "established editor cred" in pathetic disputes:

• I started editing around June 2003.
• I've contributed >26,000 edits and >250 images under multiple free content licenses.
• I have an unfathomable 2,369 pages on my watchlist, and I'm not really sure what I'm going to do about that.
• I'm an administrator on en and Commons, and that doesn't make me better than anyone else.
• On more than one occasion, I've encountered people using my contributed content in real life without knowing that I created it.
• I am done with puberty, which is bragable.

(And incidentally, like most Wikipedians, you can safely refer to me as "he".)

My POV

It's better to be open and honest about your biases so people can see clearly whether you are editing neutrally or not.

• Empiricism
• Scientific skepticism, not pathological skepticism
  • Don't believe in anything unless there is evidence for it.
  • Don't discount anything without looking at the evidence.
  • "I don't know yet" is always a valid position.
• Weak atheist (ex-Baptist)
• Evolutionist (ex-Young Earth creationist)
• Generally liberal, but that's not an affiliation. (I try to come up with my own opinions, thanks.)
• American, anti-American, and anti-anti-American
• Don't defend your beliefs; test them.

Tagline

I think we should change our tagline. Currently it says "From Wikipedia, the free encyclopedia", but this is misleading in a number of ways.

Yes, it does matter. It's not just a few inconsequential words; it's the very first impression newcomers have of our site (people visit our articles from Google searches; not the main page), and first impressions are everything. It should be short and sweet, but it should also explain the goals and functionality of the project.

i.e., e.g., etc.

I read an article somewhere that convinced me that most Latin, archaic, and foreign phrases, stuffy abbreviations, and the like really have no use in most kinds of writing, and just alienate certain classes of people, and I have been casually changing them into plain English equivalents when I run across them. Apparently this bothers some people. I'm in favor of making things as simple and accessible as possible (but not simpler).

Similar sentiments:

• Abbreviations of Latin terms like "i.e.", "e.g.", or "n.b." should be avoided and English terms such as "that is", "for example", or "note" used instead. — Manual of Style
• Be aware that you generally use abbreviated forms like these only in formal or technical documents, or documents where space is at a premium (catalogs, forms, etc.). [1]
• But even if you know Latin, simplify when writing in English! Unless you must use Latin in pompous scientific or academic documents, use for example and that is. [2]
• Toss "i.e." and "e.g." onto the great rubbish heap of Latin abbreviations whose day has passed. Instead, use "that is" in place of "i.e." (id est). Use "for example" or "such as" in place of "e.g." (exempli gratia). [3]
• The rule about using these Latin abbreviations is very simple: don't use them. Their use is only appropriate in special circumstances in which brevity is at a premium, such as in footnotes. It is very poor style to spatter your page with these things, and it could be disastrous to use them without being quite sure what they mean. [4]
• The point of writing is to be read, and if you think that there is even a middling chance that your audience will not understand "i.e." or "e.g.," don't use them. [5]
• Note, however, that it is preferable in text to say: ‘for example’ rather than ‘e.g.’, ‘that is’ instead of ‘i.e.’[6]
• IDRC style is to avoid Latin-based abbreviations such as e.g., i.e., and op. cit. The exception is et al. Sic, used in quotations, is not an abbreviation. [7]
  • (I agree with etc., sic, and et al. in citations as exceptions. Links for clarification can be good, though.)
• It is fine to include foreign terms as extra information, but avoid writing articles that can only be understood if the reader understands the foreign terms. — Wikipedia guidelines
• That is, I look at Wikipedia, and I see entries where they are using non-PlainTalk when they could just as well be using PlainTalk. And there's this thing of: "Wait, if we write in PlainTalk, then we're not a real encyclopedia. So, we're going to write the way the experts write: obfuscated and needlessly obscure." [8]
• To a newly arrived undergraduate, all university departments look much the same. The professors all seem forbiddingly intellectual and publish papers unintelligible to outsiders. But while in some fields the papers are unintelligible because they're full of hard ideas, in others they're deliberately written in an obscure way to seem as if they're saying something important. [9]

Wikipedia is not the place to build a pons asinorum. Sancta simplicitas!

On the site's functionality

Diff summaries

I think that the single greatest thing we could do to fight vandalism is implement a diff summary feature that would show a few words from the diff itself next to each edit on watchlists, article histories, and Recent changes. So instead of seeing:

(cur) (last) 14:07, December 27, 2006 81.155.109.52 (Talk) (→Permanent magnets)

You'd see something like this:

(cur) (last) 14:07, December 27, 2006 81.155.109.52 (Talk) (→Permanent magnets - Changed "protons, neutrons, and electrons;" → "poo, wee, and boogahs;")

Although it looks similar to automatic edit summaries, it's not the same thing. Those are only generated when the user changes the entire page all at once and doesn't enter an edit summary. Instead, the diff summary will always be generated and displayed alongside the regular edit summary, and will show the actual text that has changed for every diff, even small ones (especially small ones).

So, currently, you see just the edit summary typed by the user, like this:

22:37 Marcus Whitman (diff; hist) . .  (+9) . . 75.24.108.62 (Talk) (ive made it more for children!!)

If implemented, you would also see some of the diff, maybe like this:

22:37 Marcus Whitman (diff; hist) . . 75.24.108.62 (Talk) ("father's death, when" → "father went BYE BYE!!!, when" - ive made it more for children!!)

This would be kind of like the little green or red numbers next to diffs, but would actually provide real information about the edit. You wouldn't have to bother checking a diff for something like this:

22:54 Birdlime (diff; hist) . . 209.204.100.135 (Talk) (→For catching birds - "Its use illegal in" → "Its use is illegal in")

Having this for every edit would save time for everyone, help catch vandalism, and decrease server load.

Parallel discussions: Wikipedia:Perennial proposals, Automatic edit summaries, Bugzilla: 2437

Machines are meant to do work

I am generally in favor of adapting machines to humans. In a few cases it's better to adapt humans to machines, but that's just because the computer programming required, for instance, would be more work than the extra work required for each user to adapt to the machine. In most cases, when there is a conflict between convenience for humans and convenience for software, the software should be changed.

Prevent edit conflicts

We could easily prevent edit conflicts by automatically warning people that an article is being edited by someone else. It would be like the {{inuse}} warning, but it would only show up on the edit page, and it would be automatic. (And yes, you could ignore the message and edit anyway; it wouldn't lock you out.) MoinMoin wiki software has had this feature working successfully for a long time. Vote for bugzilla:1510 if you like the idea or poke your favorite developer.

Table namespace

Main page: Wikipedia:Table: namespace and editor

An alternative table editor?

A long time ago, I proposed that tables be moved out of articles and into their own Table: namespace. They would then be included in articles through a syntax similar to image syntax:

The '''world population''' is the total number of [[human being]]s alive on the planet [[Earth]] at a given time.

[[Image:World population.png|thumb|Map of countries by population]]

Below is a table of historical population figures shown in thousands.

[[Table:Estimated world population at various dates|left]]

In 2000, the [[United Nations]] estimated that the world's population

Tables clutter up the markup and are very time-consuming and unintuitive to edit in the current text-based way. They aren't very usable by non-technical types, a cause of systemic bias. (Imagine that you're editing a wiki for the first time and aren't good with computers, and then compare the above example with the real thing, which uses inline table markup.) <rant>Unfortunately, no one seems to care anymore about keeping the site editable by non-technical users. Our syntax gets more and more complicated and our article source code more and more cluttered every day. Wikipedia used to be a wiki. Sigh.</rant>

I also hoped that making tables self-contained would eventually allow magic functionality for the Table: namespace, similar to the Image: or Category: namespaces, to allow for table editing that isn't based on editing wikicode directly, so users don't need to learn pipe syntax to contribute. Maybe external editors with export as .csv or .ods files? Maybe a built-in Java(Script) editor?

This was proposed, notably, before the introduction of templates, which addressed some of the same problems (although taxoboxes and the like are now much simpler, they still clutter up the article source with lots of curly brackets), but I still think it would be a valuable addition, due to the other benefits it would provide. (Even those of us who know pipe syntax would still prefer to edit tables in spreadsheet software.)

This was proposed in January 2005, and has received a lot of support and a feature request to get it started, but hasn't happened yet. I think the only way this would ever happen is if I learned PHP and coded it myself, and even then it would take a lot of work convincing some people to include it. Another possibility is to implement some kind of javascript solution that makes tables themselves editable.

Audio pop-ups

The {{audio}} template is cluttery with all of its links. We should replace it with a javascript pop-up. This could be integrated with the proposed java media players, too.

Citations

Cite.php sucks. We need something better. If you really expect the vast majority of (non-technical) editors to cite their sources, you're going to have to make it a lot easier for them to do that.

Wikicode additions

• A way to add dashes and other typographic marks in an easy, wiki way.
  • Smart quotes
  • Double hyphen -- should be an em dash, and the like
• Super- and subscript

Diff engine

Fix the damn diff engine already. Putting a newline between two paragraphs should not make it impossible to tell if something was changed in the second paragraph. There are lots of similar problems. This is one of those things that we have all put up with for so long we've forgotten it's even broken. This functionality is fundamental to our editing.

COinS

I've been adding machine-readable COinS tags to various things around the project. See Wikipedia:WikiProject Microformats/COinS for details.

Tools

Electronics diagrams

See Wikipedia:WikiProject_Electronics/Programs.

Regular expressions

Note that these have been improved by other people. See User:Gerbrant/edit/autoReplace/default.js and User:Cacycle/wikEd for better versions

I started using some of the tools from Trilobite's page, and realized I repeatedly do a lot of the same little formatting changes to articles using the regular expression replace tab, so I created some new custom tabs to do them automatically. (This is not a bot. I run them manually on articles that I edit.) A little time programming saves a lot of time in nitpicky maintenance. So far:

• Dash fixer — ever since I learned about the differences between hyphens, em dashes, en dashes, and such (from the Wikipedia article, of course) I've become a little obsessive-compulsive about fixing them all. This tool fixes a lot of the obvious ones in one button press. Converts HTML named entities to their Unicode characters, puts en dashes between years, em dashes in place of --, and so on.
• Unit formatter — formats units according to SI. Adds spaces between numbers and units, fixes KHz→kHz, changes "5 ohms" to 5 Ω, changes Mbps to Mbit/s, and lots of other things.
• Math characters — Changes -1 → −1, 2x10^3 → 2×10³, 100 +/- 2% → 100 ± 2%.
• Heading and whitespace cleaner-upper — Adds or removes spaces and newlines so that heading markup looks as if you had pressed the + tab on a talk page, fixes capitalization of External links and See also, removes more than two consecutive newlines. I try to do this one as its own edit, since the diff algorithm can't handle it.

After you push the tab, it adds an edit summary and pushes Show changes for you so you can check that it didn't do anything bad. I might combine them together into one or something. It's good to run each separately, since one might fix things while another mostly breaks things, on a certain article. I could also make them so others can include them in their user.js and receive "updates" when I change it? If you create your own version with enhanced functionality, please let me know because I'll probably want it.

See User:Omegatron/monobook.js for details

Unwatchlist

User:Quarl has written a much better version of this, as well as many other useful scripts. See User:Quarl/monobook.js

I wrote a little script to add unwatch links to the watchlist page, so you don't have to go to a separate watchlist editing page to remove them. It's a workaround for Bug 424.

You still have to click the link and load the "Removed from watchlist" page, but it saves some steps. If you middle click in Firefox you can go through a bunch at a time.

If I really knew what I was doing, there would be a little link on the left of each article in the watchlist that lets you unwatch it, and the article link would turn gray or something to show that it was unwatched, without actually opening any other pages. On refresh the unwatched ones would disappear. I just learned how to do this much, though.

See User:Omegatron/monobook.js for details

Subpages and links

• User:Omegatron/monobook.css
• User:Omegatron/monobook.js
• User:Omegatron/Sandbox
• Meta:User:Omegatron/sandbox
• Wikibooks:User:Omegatron/navtesting
• commons:User:Omegatron/Gallery
• User:Omegatron/Gallery
• User:Omegatron test account
• Other subpages