User:Omegatron

From Wikipedia, the free encyclopedia

Wikipedia:Babel

en	This user is a native speaker of English.

fr-1

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

[edit] About this Wikipedian

I am an audio electronics engineer. I love Wikipedia. A little too much.

I claim to value my anonymity, but I'm not actually that careful about it...

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.

As of 2006, after being here for almost three years, I agree with others who think that there are some serious problems with Wikipedia's culture and quality control process. Unlike the others, I don't think the project is "doomed to failure", and I'm not ready to leave yet, but I've seen too many good, knowledgeable editors leave in disgust, and too many trolls, cranks, and disruptive users overpowering the rest and making a mess of the place. I don't have a solution.

[edit] 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. This section also explains the rationale behind some of my opinions on Wikipedia policies and practices.

Empiricism
Scientific skepticism
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.

[edit] Memory holes

I dislike it when people delete pseudoscientific articles, burn books, censor opinion, or otherwise destroy information. If an idea has a hold in people's minds, the only way to fight it is to address it and show why it is wrong, not delete it as nonsense. My first response when I see something crackpottish: check Wikipedia for an unbiased, scientific account. "Censoring" information is exactly what makes crackpot stuff take off. "Go to our website to find out what They don't want you to know!!!" Providing a good source of unbiased non-crackpot info is the only way to keep it under control. If you need to commit "memocide" to get people to believe what you believe, your beliefs are probably wrong. Improve it; don't remove it. (or Don't delete; debunk?)

I guess this makes me a crackpottery Inclusionist. See also Wikipedia:Replies to common objections#Cranks

From a memetic standpoint, you could say that this is the difference between quarantine and vaccination. Rather than trying to prevent the spread of bad memes by cutting the carriers off from society (which doesn't work anyway), we should seek to destroy the memes themselves with antibodies and set up vaccines in other people to prevent them from being contractible.

[edit] 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.

[edit] 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!

[edit] Things Wikipedia needs

[edit] Tagline

[edit] 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.

[edit] Table namespace

An alternative table editor

I think tables should have their own namespace and editor. They clutter up the markup and are very time-consuming and unintuitive to edit in the current text-based way.

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. Templates were introduced, which help quite a bit on taxoboxes and the like, but still clutter up the articles with lots of curly brackets, and aren't tremendously intuitive to non-technical types, a cause of systemic bias. I think the only way it ever would 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. See discussion and comment here: Wikipedia:Proposal for intuitive table editor and namespace.

[edit] Audio pop-ups

[edit] Citations

[edit] 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

[edit] Diff engine

[edit] Tools

[edit] Electronics diagrams

An example circuit

I have been making electronics diagrams using klunky schematic editor as a base, and then modifying and annotating the screen shots in the GIMP, a Free raster graphics editing program. They tend to be very small (~1 KB). I welcome requests and suggestions.

See commons:User:Omegatron/Gallery for examples.

[edit] Modified version of Klunky

I've modified the original version of Klunky, reducing the file sizes of the images and adding a bunch more images, such as batteries and voltmeters, and some extra functionality (generate source code suitable for posting in forums and the like). Also it just runs a lot faster if you download it to your own machine. It is available for use and download here. Just unzip to a directory and open klunky.html. The author of the original considers his version to be public domain. If you know JavaScript and want to make it work in more browsers or otherwise help me expand it, please let me know. I'd like to improve the block images and make them bigger; something like Image:Common Base amplifier.png that can be scaled down after the fact.

See Wikipedia:WikiProject_Electronics/Programs for some alternative programs. There currently isn't one that fulfills all of our needs, but xcircuit is probably closest.

[edit] Spell checker

I sometimes spell check entire articles with the Spellbound extension in Firefox. I have the American, Australian, British, Canadian, and New Zealandic dictionaries, but use the American or British for convenience. If there is a mix of words from both I use whichever is the majority for consistency. ("Note that the English form of Wikipedia has no preference for American, British or other forms of English so long as this is consistent for the whole page.") Occasionally it "corrects" a word wrongly and I miss it. Sorry.

Guidelines for changing dialects:

If you think a page should be in a specific dialect because of the subject matter, like Department of National Defence (Canada), point it out and I will run through it with the appropriate dictionary.

One problem with spelling correction is that poor spelling is often an indicator of poor content... Oh well.

[[User:Omegatron#Spell_checker|Spell checker]] — using US English

[[User:Omegatron#Spell_checker|Spell checker]] — using UK English

[edit] Regular expressions

Note that these have been incorporated into User:Cacycle/editor and improved

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

[edit] 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~~

[edit] Subpages and links

	Multi-licensed with the Creative Commons Attribution Share-Alike License versions 1.0 and 2.0
I agree to multi-license my text contributions, unless otherwise stated, under the GFDL and the Creative Commons Attribution Share-Alike license version 1.0 and version 2.0. Please be aware that other contributors might not do the same, so if you want to use my contributions under the Creative Commons terms, please check the CC dual-license and Multi-licensing guides.

Retrieved from "http://en.wikipedia.org../../../o/m/e/User%7EOmegatron_4264.html"