Talk:Wikimark2

I have created this proposal and I think it has merit. However I am unsure of how to get feedback, where to post it, or whether I've even put it in the right place. I assume Meta is nice enough to allow the proposal in the main namespace, like Wikitax. I also think the proposal is enough worth considering to merit its own page, to coordinate its growth.

If there is a place to announce proposals like this, someone please do it for me. --Alfakim 22:26, 30 May 2006 (UTC)

Comments

There are lots of good things here, some of which would go well with existing Wiki markup. Things I like:

• -- = emdash (could be incorporated immediately)
• Automatic conversion of &nnn; notation. (could be incorporated immediately)
• Consistency of "in" links and "out" links. The [[Category:]] notation is one of the real banes of wikimarkup.

Things I don't like:

• *bold* notation. Looks like a recipe for trouble. You'd need nowiki tags to notate a dos file mask: *.* - doesn't strike me as intuitive. IMHO, more "intuitive" is to make every syntax element a doubled character - **bold**, //italic// etc. That would be a hell of a lot better than our apostrophes - **//Gone with the Wind//** instead of '''''Gone with the Wind''''' was a film that...
• Line breaking depending on ending of previous line is not intuitive to me - I would never, ever guess that that's what was going on.

Other comments:

• <<, >> for nowiki syntax sounds good. Presumably <<<<>> would produce a literal <<, while >> would produce a literal >>
• [[page|alt]] notation isn't bad enough to worry about - you catch on pretty quickly when learning wikimarkup, even if the arguments did strike me as "backwards" for a long time. And the "pipe tricks" are so handy that losing them would be a shame.
• Don't understand the section about inheritance. Stevage 07:56, 31 May 2006 (UTC)

How are interwiki language links handled? Is a link to the French version of a page an "out" link or an "in" link? Stevage 07:44, 31 May 2006 (UTC)

Interwiki isn't part of the article text, so it's an element added to the raw content. Hence an "in" link. Updated above. --Alfakim 13:46, 31 May 2006 (UTC)

Thanks for reading, I have some replies.

• You've made a very, very good suggestion with the doubled syntax elements. I shall change all tags now to doubles, thus making this language even more consistent.
• The line-breaking isn't meant to be intuitive; rather, it solves problems without the user realising, i.e. it's an automatic parsing error-fixer. A lot of people post on MediaWiki with stuff like:

here's my poem:

in the day,
flowers of may;
hay oh hay.
Yay!

Did you like it?

The new syntax would thus format this correctly for them, so long as they've punctuated correctly. manual line-breaks will be done differently.

• Inheritance meant we inherit those parts of the old wikitext language.
• I've defined a function for <<>> now; tell me whether you think the use of it is worth trumping "<< nowiki text >>".
• I am still considering pipe syntax. Pipes are currently used for tables, which clashes with their use for parameters. --Alfakim 15:29, 31 May 2006 (UTC)

Automatic dash conversion was included in MediaWiki 1.5 alpha 1 about a year ago, but it was disabled here. The Goings-on announcement about that feature didn't get archived, but the Vietnamese translation of it is still there. Perhaps there's some explanation at the mailing list as to why it didn't get enabled on the MediaWiki wikis. – Minh Nguyễn (talk, contribs) 01:23, 1 June 2006 (UTC)

Yes I remember that, but I never figured out why they disabled it. I cannot see a problem that could arise from it. --Alfakim 14:47, 1 June 2006 (UTC)

Decrement operators in programming languages? æle ✆ 18:39, 6 June 2006 (UTC)

Mediazilla:1485 discusses the issue. Apparently there wasn't necessarily an inherent problem, other than that people couldn't agree on what should translate to what, but the implementation screwed up with hyphens in markup. —Simetrical (talk • contribs) 22:44, 6 June 2006 (UTC)

I like the "in" and the "out" links very much. I could get used to the <<>> for wiki functions. I think it's a bad idea, however, to use the same symbol for the unordered list and for bold markup. It also seems counterintuitive to parse from the right. I don't like how the beginning and ending of tables is defined by a blank line. It seems like this would be a headache when working coordinating with templates. — It's dot com 03:10, 3 June 2006 (UTC)

Agreed. Suggestions? As for the tables, no, it would work just as easily (hardly) as we currently have it for tables in templates. As for the bold markup and the list markup, both are intuitive so i dont want to really get rid of that. in case you think it would cause parsing errors, it won't. parse direction simply avoids errors; so long as tags are closed properly (defined as strict) it'll be the same either way. if they ARENT closed properly, parsing from the right merely avoids errors. --Alfakim 12:53, 3 June 2006 (UTC)

So...

Who's going to make the parser? :o) (never underestimate the hideous complexity of Parser.php) (although maybe this time we can get proper tag balancing and some unit tests) — Ambush Commander^(Talk) 22:52, 31 May 2006 (UTC)

No idea who would make the parser. I understand PHP and how it all works - and I'm considering that as I write this page - but I'm no way good enough to write it myself. This page is currently just here for discussion and to design the language. If it gets any kind of support, we can think about writing the parser THEN. --Alfakim 14:45, 1 June 2006 (UTC)

infered line breaks

This change does not add value and will in fact break too often, notably when a break is infered from a line ending with comma. Why infering breaks? it's not needed. Let's keep the empty line as the only explicit paragraph break. otherwise we'll get plenty of articles edited with external editors that force line breaks at any place in the middle of a paragraph.

Why not keeping the convention already used in email where line length is also constrained? Let's not introduce a kludge with a future requested backslash at end of lines that must not break!

---

Also why changing both bold and italic (currently marked with single quotes)? It seems that introducing ** as the bold mark will now conflict with the * used in bulleted lists! Hmm... what about ++, %%, $$, !!, ??

86.221.102.98 15:35, 4 June 2006 (UTC)

Good points. The inferred linebreaks MIGHT be a problem, so perhaps you are right that they should be removed. (Support, anyone?). The ** and // italics and bold tags are used as intuitive. Lots of programs (eg Google Talk, Word) already use ** to mark bold. An alternative might be:

+italics+

++bold++

+++bold italics+++

Discuss! --Alfakim 14:46, 7 June 2006 (UTC)

Having + for italics might interfer with actual math formulas.

Why not use the single quotes that we've already got? They seem intuitive enough. --151.213.235.211 03:29, 7 July 2006 (UTC)

What about migration? other syntaxes

It seems that such change will have a huge impact on migrations.

So may be it could be implemented by not changing the existing articles, but only marking those that have been edited with the new syntax (an attribute in the database?), and by offering a way for users to edit it in the previous syntax for some time (notably for those users that are running maintenance scripts and various external tools and bots performing typographical corrections).

Be aware that this will take time for users to make the correct shift to the new syntax. And converting the whole database will take too much time and will probably introduce many errors, because there may already exist lots of articles where the new reserved sequences are already used, and that will require manual conversion to make the correct changes for the newer syntax.

Why not using the MIME type attribute of articles and medias to store the syntax type used when editing the articles? And why not finally adopting a XML-only syntax for articles, that will be simpler for the server to parse (notably for templates)? The wiki syntax may be generated from the XML source for editing, and the interpreted version will be stored in XML format.

Editing in XML format will be possible but saving XML will be accepted only if it respects the strict XML conformance. A good XML based syntax to support would be DocBook...

Finally, it should be possible to edit an article in ASCII only (for program sources or texts that remain to wikify), without having to worry about syntax on first edit. When saving, the equivalent wiki format will be generated, and the user will be able to add enrichments like bold, titles, joining paragraphs, etc. The first viewed version, if not edited will be saved as if it was a <pre> section, i.e. with a leading space on each line, and with all special characters correctly quoted to avoid special semantics.

So for me it seems more important to keep the syntax as it is now, but to accept alternative syntaxes for new articles, and to offer tools to make the conversion when necessary. All those alternative syntaxes should be kept in the database as is, without requiring any conversion.

There are for example competing syntaxes for wikis using other softwares, that would really like to switch to MediaWiki, if it could support their existing syntax. Or may be they are already candidates to close their site soon (with interesting results that should be kept somewhere when the site will close soon), and find a place to publish their content somewhere else, such as a MediaWiki server, where it could be used as a test, for later integration of articles in Wikipedia, or Wikibooks, or Wikisource.

The conversion of syntax from various public sources is troublesome, and if MediaWiki could support several syntaxes, it would ease the migration, without having to edit the imported articles.

86.221.102.98 16:16, 4 June 2006 (UTC)

You make many good points, although i'm not a whizz on the xml and mime stuff. Anyway:

1. Converting to new syntax. I've tried to design this so there won't be a problem. This new syntax just rearranges the old one. There may be errors where new syntax has been used accidentally in the old, but i think this would be easily corrected.
2. Option for old syntax. Not sure. It's a good idea to wean people into the new one, but i hope the new one is enough like the old one (and makes enough sense) for the crossover to be easy enough.

--Alfakim 14:50, 7 June 2006 (UTC)

Other ideas: linking

Another thing to consider is to allow the autodetection of possible links in articles when saving it: words are parsed, and if they match an article name (not a redirect), the first occurence in the article will be marked with the detected links.

We have articles for a, of, the, and and. It could get confusing. æle ✆ 18:41, 6 June 2006 (UTC)

A bit dodgy. I like to define links myself. --Alfakim 14:51, 7 June 2006 (UTC)

Well, there could be a tool implemented before Wikimark2 that suggests possible links. This would be optional, so that one could simply press a button to see what pages there are to be linked to, and one could just 'check mark' boxes for links one wants in the article. Auto-links would be way insane, as many, many words would be linked. I love the auto-linking idea, just tweaked. Scepia 03:36, 21 June 2006 (UTC)

Other idea: a new namespace for synonyms

To sovle the problem of the detection of ambiguous article names that link to multiple pages, and that should better not be used as the target of links, why not having a synonym namespace (for example "=:"). The content of pages in this namespace would bne what is currently found in synonym pages, or diambiguation pages. In pages of this disambiguation namespace, the links to the articles would also start with a short prefix like [[:=:Article name]], while other links used in that page for explaining the role would be normal links.

This would allow easy cross reference of all articles linked from the same disambiguation page of the special namespace. Conflicting articles would be easier to link with it, and it would be easier for the various articles related to the same synonym to be found.

Some examples:

The small abbreviation and codes are often creating synonyms; these synonyms must be explained with an extra reference to the standard in which the code is referenced, but the code itself will point to a unambiguous article like a country name, a language name, an actual word of the language, a small article about a trademark or company or product name, or the complete name of a timezone...

For this we need a disambiguation page named [[=:IO]] for the ambiguous code IO. When using the search functiuon in Wikipedia, it will first look into this namespace before looking into the article namespace. When someones types "IO" he will then see the disambiguation page [[=:IO]] where he will find the various meaning of this as a [[ISO 3166]] code pointing to [[=:British Indian Ocean Territory]], or as meaning [[=:Input/output]] in [[computing]] technology.

Sounds a bit too complicated and unintuitive. Also, namespaces aren't controlled by the syntax. Namespaces which function specially are even MORE not controlled by the wikitext syntax. The change you describe above is really not related to a new wikitext, and should probably be discussed as a seperate proposal. It's interesting but i see that it might have some problems. --Alfakim 14:52, 7 June 2006 (UTC)

This is great but could be more forward thinking

I love this markup as a person who doesn't even know html (although I have been forced to pick up a little). I think this addresses most of the usabilty concerns of the curent markup. However it addresses none of the concerns that are currently unaddressed by wikimarkup. Wikimarkup is actually rather limited. Most wikipedia editors probably do not realize this as WP has adopted a publishing style that is within those limitations. This is not good enough for other applications. WP articles have disregard alot of formatting options to focus on content. Even at other projects this can swallowed since formatting is usually of minor importance. However the flaws become obvious when you start working with poetry. Formatting cannot be ignored. I do not understand the infered line breaking section, but I think it is not enough for poems. We need a way to force line breaks, especially if html is not allowed. Also we currently rely on a template to make proper indentations. The complex reason we cannot use wikimarkup are found here, the solution discussed (editing the stylesheet) was not implemented. The above template was created afterward. Centering text is another issue. Even relatively centered text would be agreat improvement. Text sizing also. I am sure there are other things as well that I cannot think of right now. Something that would help make index pages, although we can always use tables if nothing else. But open up some older books especially and look at variety of formatting that was used not so long ago. Think about other applications as well, I am sure Wikisource is not the project that feels hampered.--BirgitteSB 02:40, 5 June 2006 (UTC)

Every single thing you mention can be done with HTML, specifically via insertion of appropriate CSS style traits in divs. Quite simply, the functionality that you want is so complex that it would be insane to make a completely new markup language to cover it all.

1. Force line break. <br />.
   This follows a forced line break. (br stands for "break".)
2. Indentation. <div style="text-indent: length;"<text</nowiki>. length can be in: em (width of a lowercase m in the font), ex (height of a lowercase x in the font), px (pixels), or—in general less usefully—in, cm, mm, pt, pc (inch, centimeter, millimeter, point, pica). (The latter measurements are typically converted to pixels for browsers, which don't know how big your monitor is, but may be interpreted literally by printers.) For instance:
   This is indented 1in with respect to the containing list element.
   This is indented 2.5em.
   See [1]. Editing the stylesheet could be useful, but is certainly not necessary: the relevant style attributes can be included directly inline, perhaps by a template if standardization is desired.
3. Centering. <center>text</center> works. CSS aficionados prefer the longer and clumsier <div style="text-align: center;">text</div>. Either one will typically result in a linebreak; if this must be avoided, there may be a way around it using a table or CSS boxes.This is HTML-centered.
   This is CSS-centered.
   I'm not sure what you're contrasting with "relatively-centered". I believe CSS can center with respect to things other than the containing element, but I have to know exactly what you want.
4. Text-sizing. <span style="font-size: size;">. Possibilities for size are at the W3C site. This is "larger". This is "x-small". This is "16pt".

When it comes down to it: if there's formatting you want that HTML and CSS can't do, there's no way to do it, because the page (like all Web pages) is written in HTML and CSS. I don't think it would be useful to try to rewrite such complex languages, because you aren't going to be able to simplify them much but you will force everyone to relearn them.

(I'm not watching this page, so drop a note on my talk page if you want me to respond.) —Simetrical (talk • contribs) 22:30, 6 June 2006 (UTC)

Yes I realize these things can be done. Some of them rather easily others not. The proposal however does say: Text placed between <singular triangular brackets> is always HTML - alternatively, no HTML is allowed, full-stop. If HTML is not allowed these funtionalities will be lost. I do not see why some them can not be made more intuitive any case. Are they really more insane than tables?--BirgitteSB 23:51, 6 June 2006 (UTC)

Yes, they're more insane than tables. There are 115 properties in CSS. Disallowing HTML is doable, although perhaps unnecessary; disallowing CSS is ridiculous. —Simetrical (talk • contribs) 06:35, 7 June 2006 (UTC)

About forward thinking

You're discussing NEW functions to wikitext, whereas I have been focussing on just making existing functions easier and more intuitive. So you're right that this isn't very forward thinking. To introduce new functions might require higher approval (there's a reason, i suspect, why extra formatting isn't allowed - as you say, we're focussing on content). I think we should first focus on redesigning the current wikitext before expanding it. --Alfakim 14:57, 7 June 2006 (UTC)

I would say the reason some extra formatting has not been allowed is it was not of much importance to an enclyopeadia, but Wikimedia has grown beyond that now. I cannot think of a better time to think about new functions than when a re-vamp is underway. In any case after looking at the CSS examples above, I think we should forget about disallowing HTML. The CSS way of producing the basic HTML that I have actually managed to learn is not acceptable for a wiki where editors are not expected to be web designers.--BirgitteSB 16:49, 7 June 2006 (UTC)

Okay then. But i still think we should focus on the revamp first. Rewrite all the functions of the old wikimarkup into this newer, more consistent language, THEN add extra stuff. --Alfakim 20:16, 7 June 2006 (UTC)

Okay, but just make sure to allow HTML.--BirgitteSB 17:14, 8 June 2006 (UTC)

{{Media:

Shouldn't it be [[Media:, because it's a link? æle ✆ 18:42, 6 June 2006 (UTC)

Well it's both. [[Media:]] would be a very simple link: Media:. Inline, and so on, linking to the page for that media file. {{Media:}} actually inserts a little box the way you see it in articles, the clicking of which directly opens the file. So in this latter sense it becomes an inserted element. --Alfakim 14:58, 7 June 2006 (UTC)

So media:blah would insert an inline link to the media descript page, not directly to the media as it currently does? Bawolff 06:32, 8 June 2006 (UTC)

Yes that's right. All square codetypes insert a very normal link to the description page. You insert it specially (as an element) with the braces codetype. --Alfakim 21:58, 8 June 2006 (UTC)

Support

I strongly support many ideas here, but beleive the dounting task of reeducating contributors might kill it from the start. Can we possibly have two editor screens, possibly even javascript based so that wiki markup gets converted from legacy to new form and back with a single click? --Yurik 14:35, 7 June 2006 (UTC)

Well, most of Wiki2 is the same as the original, there are just changes to make it more consistent. There would be a few months where there might be problems. So i think it could be achieved by allowing either syntax to be used for a while (a radio button somewhere), followed by a slow move into all-new. --Alfakim 15:00, 7 June 2006 (UTC)

No accidental interpretation

What I like in the current wiki markup is that there are few cases when it accidentally interprets something as markup when I intend it as text. This is why double square brackets are required to make a link: so that you can write single square brackets easily and don't have to escape them. On the other hand, double square brackets are not required for external links because it's not so frequent that you want to write a bracket and an url scheme like "[http://" when you don't mean a link.

Now this is what I don't like in your proposal. You recommend that angle brackets be always interpreted as html markup. That's wrong, because then you must escape every occurrence of angle brackets. The same applies to the backslash character.

I also don't like the rule that empty cells in a table implying row spanning, which you contradict to right in the example at column spanning. This exampls shows greatly that you do write such a thing accidentally, so it shouldn't be interpreted as markup. – B jonas 15:12, 7 June 2006 (UTC)

I didn't notice that contradiction and will fix it. As for your points, I can't see anywhere in an article that you really need double square brackets, that's exactly why they are used. This new syntax allows single square brackets as just text (which ARE used). So i'm not sure i see your point.

I believe B jonas was talking about <<angle brackets>> which are used in French as "quote marks" are used in English. Please corrrect me if I am wrong.--BirgitteSB 17:00, 7 June 2006 (UTC)

Good point, although I believe the French use a proper character, not a double triangle like that. Nevertheless, if they do, then such usage will be sufficiently rare to merit escaping; even if they are not escaped, all that will happen will be that the text cant use markup, which is usually the case for a quote anyway. So my point is, yes, i see what you mean, but it's a minimal problem. --Alfakim 20:12, 7 June 2006 (UTC)

It wouldn't be a problem... if all the French users had special "French quote mark" (U+00AB, U+00BB) buttons on their keyboards. But I'm sure many don't. Heck, if everybody used "prime" U+2032 or "apostrophe" U+2019, we could use the common-and-garden single quote for wikisyntax. R3m0t 15:56, 11 June 2006 (UTC)

1. <<This just won't parse as a function because there isn't one, so it's not a problem>>
2. I see your good point, but no way to work around it without saying that functions must all start with something similar. For instance:
   • <<#ref blahblah >>
   • <<function:ref blahblah >>
   • <<:ref blahblah >>

--Alfakim 15:15, 13 June 2006 (UTC)

Table parameters

I have defined parameters as "stuck to the closing tags and seperated by pipes". This is not the case for tables yet. Table parameters avoid pipes so they dont interfere with template code. However, is this unintuitive? Perhaps all parameters should follow the same pattern. If so, a cell's parameters ("align=right" etc) would be thus:

 
!! 1:1 |right!! 1:2 !! 1:3 |c2!!
!! 2:1       !! 2:2 !! 2:3    !! 2:4
 

Yes/no? --Alfakim 15:37, 7 June 2006 (UTC)

Too important to miss; implemented. --Alfakim 20:05, 7 June 2006 (UTC)

Hmmm... that looks a little confusing. --151.213.235.211 03:39, 7 July 2006 (UTC)

Comments on the autoparameter for links

Interesting idea. A lot of these pieces could be extremely useful. I agree with a lot of the comments already made here, so I won't reitereate them, but one I don't see: I'd rather you flip the external link pipe trick. That is, let [[http://www.wikipedia.org]] leave [2], and let [[http://www.wikipedia.org|]] leave http://www.wikipedia.org. This is because having the link collapse into something small is far more common a thing to want than the other way around, and should thus be simpler to type. Drawbacks: less intuitive, but then I think that I'd rather have the ease of use once I'm past the learning curve. Thanks for the page, these are some great ideas! Snoutwood (talk) 17:38, 7 June 2006 (UTC)

I disagree. It's very rare that you actually want a link like this - [3] - in your text. In nearly every case you're going to want a full URL or else an inline ref that cites it properly. Eg:

• Links: http://www.foo.com

...blah blah as seen online. Blah blah...

--Alfakim 20:07, 7 June 2006 (UTC)

It's perhaps not so common in articles, but it's massively common elsewhere (say, for example, talk pages and noticeboards). In articles, you generally would want a full piped link with an entirely different title. Almost never do you want the full URL (i.e., http://www.wikipedia.org) to be shown. Thus, it shouldn't have the easiest markup. The most common usage should have the simplest markup. Snoutwood (talk) 21:44, 7 June 2006 (UTC)

You have a point, but I prefer to retain consistency. [[Foo (word)]] gives Foo (word) (not something else, e.g. Foo), so [[http://www.foo.com]] should give http://www.foo.com, not something else. --Alfakim 22:00, 8 June 2006 (UTC)

Sure, that's sensible enough. Snoutwood (talk) 00:27, 9 June 2006 (UTC)

Some more comments

• Code types - Requires slight rewording, as currently the links don't show, as they can't insert a link text.
• Wiki-functions - Nice idea, if it can be parsed, and can be written without the need of an escape character.
• External links. Not all URI-s contain ://. Also, while I would love to drop the heritage []-function, putting this into ordinary links means you need something to tell the parser you are actually making pages about web sites. Possibly you're defniing a leading : again, here.
• Media - A link to Media:foo.ogg does not actually insert the sound. Description should probably match intended functionality.
• Categorisation and interwiki (called "interlanguage" here) - These do not insert or link anything into the raw text. They are probably wiki-functions.
• Subst - Obviously, though you could allow legacy-functionality, it should have a consistent implementation as well. The test for usefulness will come from checking that the consistent implementation is indeed easier to use.
• Leading space as a nowiki wikifunction shortcut - This is quite handy, and would also be quite an irritation. Unless you go for no spaces allowed all around, don't break consistency here. <<| <<! <<- <<=
• Wiki function arguments - As can be seen from the examples, this no space rule reduces readability. Don't. If it's there for a problem, a different solution is needed.
• Example for Category - Appears to have the same limitation as the current implementation. May be intentional, but still. (<<Category Proposals|W>>)
• Autoparameter for links - This will not help us link within a namespace in any way. We don't just want it to strip stuff, we also want it to prefix the link with the Namespace the page is in, if no Namespace is present.
• Autoparameters for external links - Beep. That's an inconsistency. So, I expect it's really going to strip the protocol etc., the pseudo namespace, while a real argument creates the note style? And of course, this being the same link as the internal link, this means this argument will be available there as well, which will allow real notes.
• Escape - No. Escape characters are for programming, not for writing. If you need them, it means you've lost consistency or clarity.
• Text styles - The advantage of the wiki syntax is it's silence. Yours draws away the attention that should be on the text.
• Third-level point inexplicably ending with 2 asterisks - Neither the code, nor it's representation comes out right here.
• Headers - These imply text styles and should likewise be tag-styled.
• Automatic line break
  • Would break up any text where the author decided to start on a new line for whatever reason, just in case she did so for one specific reason.
  • You're example here shows you actually want this to trigger on punctuation that is no line ending. While everybody understands the problem you're trying solve, though they may not know the solution, most people will not even understand the problem you're introducing. New line, which in itself isn't even visible, is going to behave differently depending on what was on the previous line.
• Indentation - Don't work backwards. Right indent should be indicated before the text. Probably shouldn't be line based all.
• Blockquote . Bad choice of words. A blockquote is not an indentation style. Itmight actually take the whole page width on a page where normal text leaves an annotation margin.
• Dashes - Automatic conversion is everybody's favourite, until it does what they don't want.
• Tables
  • Not actually any more readable than the current version.
  • <<br>> creates a new line in the cell; that doesn't help to create a new row.
  • Aliasses - Aliassing all attributes and style attributes will create quite a monster. So if you make a choice, what is your reason for what you do implement?
  • Row control - This breaks up the piping; what does that mean for text inserted between other !!-s?
  • Spanning - Needs a disambiguation for a non-existant cell with top and left neighbours.
  • Fake first row - Beep.
• Mark 2 - This is probably an improvment to some, but it will be considerably set-back for others. If you want to be able to use this mark-up, look for a way to introduce a choice of mark-ups.

Aliter 22:59, 7 June 2006 (UTC)

Brilliant points. I will implement as many as possible. Some were quite unclear though. --Alfakim 22:12, 8 June 2006 (UTC)

Generally excellent, some flaws

1. The entire idea of <<tag>> markup is not good. You're talking tags that are often used to enclose large amounts of text, so it would be easy to lose track of nesting or to encounter a >> and think "Wait, what's that closing?". The excellent point about SGML-style tags is that closing tags are unambiguous, which is critical for such large spans. (The alternative used in programming, signalling attachment by indentation, would work equally well but is impractical here.) Keep SGML-ish things like </nowiki>, don't introduce such confusing markup.
2. Using double brackets for both internal and external links is a good idea. However, if the target is a URL, a space should optionally be permitted as a separator between target and text. This is because URLs can be long and unwieldy in the edit window, and if you force the first word of the displayed text to be tacked on to them following a pipe, they'll get even longer and more unwieldy. Space as a URL delimiter is entirely unambiguous and should be kept.
3. lc and uc are pretty pointless. Use CSS instead.
4. An escape character as simple as a slash isn't really acceptable in plain text. Characters will be acting up for no discernable reason. Use the lengthier but clearer <nowiki>, or HTML escape codes if you want something shorter but indecipherable.
5. The change to headers really makes no difference in terms of simplicity.
6. Inferred line breaks, I'm sorry, don't make a lot of sense.
7. > for indentation may not be as good an idea as the current :. The former is already used for all HTML and other SGML-style tags, so conflicts may arise unnecessarily (remember how single linebreaks are completely ignored).
8. Your scheme for auto-hyphenation is probably the best I've seen. I don't think there would be any case where it would give an incorrect result. (En dashes for things such as date ranges would, of course, still have to be entered manually.)
9. Problems with your approach to tables:
   1. You make no provision for easy use of header cells (since ! is used for everything).
   2. You force all cells in a row to be on the same line in the edit window (which is perfectly fine for the tiny cells you use for demonstration, but impractical for lengthy cells: the option has to be there).
   3. The <<table ... >> is a minimal improvement, if any, over the current {|.
   But there are good points that should be adopted:
   1. Implicit row-starting. I think the best way to handle this would be to have ||/!! starting a new line to indicate a new row. If row properties are desired, the old |- should be used.
   2. Automatic row- and column-spanning. The current parser assumes omitted cells are meant to be blank, which is probably less likely.
   The misinterpretation of pipes isn't inherent to the use of pipes for tables; it's a simple bug (Mediazilla:4060) which will certainly be killed in a parser rewrite like this.

Other than that, I basically think this would all be somewhere between good and excellent. Hopefully we can get some enough community support that this is lumped in with the parser rewrite.  :) —Simetrical (talk • contribs) 04:54, 8 June 2006 (UTC)

Again, some really brilliant points, I will implement as many as possible. --Alfakim 22:12, 8 June 2006 (UTC)

transcluding images

Looks very intreasting. One problem I see is how do you transclude an image description page? Currently you'd do a {{Image:En-wikipedia-111111.png}}:

File:En-wikipedia-111111.png

Bawolff 06:30, 8 June 2006 (UTC)

In this syntax you'd do: <<msg Image:En-wikipedia-111111.png>> --Alfakim 12:59, 9 June 2006 (UTC)

Common Syntax for Inclusions, Functions, and Links

I like the idea of functions, inclusions, and links being similar in markup. However, it would be much easier to parse objects if their syntax was consistant. Since the parameter delimiter for links and inclusions is already a pipe, why not use a pipe for functions as well.

[[link|alt]]
<<function|operand>>
{{inclusion|param}}

There is already a decent parser for templates using this syntax in 1.6.x. It could be extended to handle links and functions as well. If the long term goal is to create a syntax that can easily be converted to other formats for use by WYSIWYG and third party editing tools, we need to make the markup consistent.

This "common syntax" is already there. Except it's:

[[link|alt]]

<<function operand|param>>

{{inclusion|param}}

The function is like that because the operand isn't a parameter. See the ref example. --Alfakim 13:00, 9 June 2006 (UTC)

Yeah but that's just because that's the way it's done now. Why not just say that the first parameter to the function is the operand?

Because that isn't always the case, esp. with templates. --Alfakim 15:12, 13 June 2006 (UTC)

I don't think I'm getting my point across so one last try. All three of these things are similar. They all have two opening characters, element name, one or more parameters, and two closing characters. The only difference is that the function, as it stands now, uses a space before the first parameter instead of a pipe. You can call it an operand or a parameter or whatever you want but the parser is going to treat it in exactly the same way. If you use a space instead of a pipe for the first parameter, in the parser, you are going to have to have two different cases: one to handle links and inclusions and one to handle functions. If functions also used a pipe, all three of them could be parsed exactly the same.

de-indenting. nonono. functions still use pipes for parameters. but the bit seperated by a space isn't a parameter. let me explain. whilst links and inclusions dont have inputs, functions do. in the current syntax we do:

<ref name="parameter"> input </ref>

the input is not a parameter. in the new syntax this becomes:

<<ref input |name=parameter>>

ie, we simply remove the need to repeat the tag around the input, and use only 1 function name to surround the input. --Alfakim 02:44, 16 June 2006 (UTC)

I'd be all for namespacing these tags. <ref></ref> becomes <wiki:ref></wiki:ref> — Ambush Commander^(Talk) 03:00, 16 June 2006 (UTC)

Explain? (point of that)--Alfakim 16:57, 17 June 2006 (UTC)

idea for unordered lists

currently an unordered list begins with *. That's intuitive. And then bold is surrounded by **two stars** - the stars are intuitive. these conflict, so one needs to go. But i realised that also intuitive for unordered lists is -:

- point 1
- point2
-- subpoint

might this be an acceptable change? --Alfakim 13:40, 9 June 2006 (UTC)

Mh, yeah, makes sense to me. —Nightstallion (?) 23:42, 10 June 2006 (UTC)

Bah!

I just stumbled accross this page, I think it's a horrible idea. The new image syntax would break every image on the wiki. (let's get some backwards compatibility, please) I think Wikimarkup is fine as-is. It is simplistic, readable and easy to pick up on. This code you propose, yes it has more features, but it is just to complex. As einstein said: Everything should be made as simple as possible, but no simpler.We want more editors, so let's not scare them off with ... functions? Just to note: converting all the different wikipedias, wikiquotes, wikisources and the rest would sapo the life from the servers for an unacceptably long amount of time. The developers just wouldn't take it unless it was backwards compatible (maybe update in phases?) MichaelBillington 01:13, 11 June 2006 (UTC)

The "functions" can be renamed to something else, but most people know what "function-ality" means. Obviously the wiki would be converted to the new syntax, so it wouldn't "break every image on the wiki". R3m0t

Quite. I in fact think this markup is simpler than before. It's just being discussed here in technical terms. --Alfakim 15:12, 13 June 2006 (UTC)

Table/HTML + Indentation?

How do these parse?

<<table
!! 1 !! 2 !!
!! 3 !! 4 !!
>>Indent me!!

<<table
!! >>Indent Me NOW!!!! !!
>>

>>>This paragraph is really indented but not to be confused with a
<<table which would be slightly less indented

<div id="hmm"
>quirky but valid?</div>

Hahaha that was funny. I'll sort this out. In the last example the div is broken so it wouldn't parse as one.--Alfakim 15:11, 13 June 2006 (UTC)

You know... It looks broken, but I think it is valid HTML.

Newlines are valid whitespace. It's definitely valid. — Ambush Commander^(Talk) 18:58, 15 June 2006 (UTC)

functions are a bit awkward

I know you want to keep everything consistent, but functions are, in their current form, a bit strange.

With all other uses of pipes, the pipe always come directly after what they are being applied to... but with functions they come directly after the input... which is pretty confusing. And, as mentioned above, having an ambiguous >> for closing functions might become confusing to the reader.. how about this. So far, all the examples have been really simple, but when you start getting into more complex instances, it becomes very confusing. So, here's my proposal...

Instrad of:

<<function 
Hey this is totally inside a function, oh my god. I totally can't believe how functionized this  
paragraph is.. it has specialy parameters that other bits of text don't have and that is so super   
awesome. All of this massive text is directly inside the function tag, which I think is super   
cool. <<otherfunction oh and look this text is in EVEN MORE FUNCTION... whoa... mind boggling 
stuff... I mean look at how cool and unique THIS text is... it's really awesome 
|meh="bleh"|gray="green"|there="IsNoSpoon"|align="ChaoticNeutral"|"fish=tank"|"yummy=muffin">> 
anyways this is still totally awesome I love how awesome this is |foo=bar|potato=tomato|it rains in 
spain, but mainly on the plain="corn chips">>

Which is confusing as hell... let's do this instead:

<<function |foo=bar|potato=tomato|it rains in spain, but mainly on the plain="corn chips">> 
Hey this is totally inside a function, oh my god. I totally can't believe how functionized this  
paragraph is.. it has special parameters that other bits of text don't have and that is so super   
awesome. All of this massive text is directly inside the function tag, which I think is super   
cool.<<otherfunction|meh="bleh"|gray="green"|there="IsNoSpoon"|align="ChaoticNeutral"
|"fish=tank"|"yummy=muffin">> oh and look this text is in EVEN MORE FUNCTION... whoa... mind  
boggling stuff... I mean look at howcool and unique THIS text is... it's really awesome
<</otherfunction>> anyways this is still totally awesome I love how awesome this is.
<</function>> 

And that's still a common example... despite how long it is in comparison to all the short examples used. What do you think? --151.213.235.211 04:35, 7 July 2006 (UTC)

I agree that the functions are very dodgy in this, but I want to avoid the XML-style closing tags. how about these?:

<<function|param|param|param : input>>

<<function|param|param|param
input>>

in the second example above the new line differentiates parameters and input. --Alfakim 14:32, 7 July 2006 (UTC)

Improve table syntax first

A lot of improvments over the current wiki syntax in your proposal, except where current wiki syntax sucks the most which means : tables.

See for example the code for this nice-looking result table for the current world cup of football available here  : fr:Coupe du monde de football de 2006

Groupe A
	Équipe	Pts	J	G	N	P	BP	BC	Diff
1	Allemagne	9	3	3	0	0	8	2	+6
2	Équateur	6	3	2	0	1	5	3	+2
3	Pologne	3	3	1	0	2	2	4	-2
4	Costa Rica	0	3	0	0	3	3	9	-6

Nice, uh ?

But the code is absolutly ugly :

{|border="0" cellspacing="0" cellpadding="1"
|-
|colspan="10" style="background:#98A1B2;color:#FFFFFF"|'''Groupe A'''
|-bgcolor="#E4E4E4"
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"| 
!style="border-bottom:1px solid #AAAAAA" width="150" bgcolor="#F0F0F0"|'''Équipe'''
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|Pts
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|J
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|G
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|N
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|P
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|BP
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|BC
!style="border-bottom:1px solid #AAAAAA" width="20" align="center"|Diff
|-align="center" bgcolor="#CCFFCC"
|1||align="left"|'''{{GER football}}'''||9||3||3||0||0||8||2||+6
|-align="center" bgcolor="#CCFFCC"
|2||align="left"|'''{{ECU football}}'''||6||3||2||0||1||5||3||+2
|-align="center" bgcolor="#FFBEBE"
|3||align="left"|''{{POL football}}''||3||3||1||0||2||2||4||-2
|-align="center" bgcolor="#FFBEBE"
|4||align="left"|''{{CRC football}}''||0||3||0||0||3||3||9||-6
|}

Does it look better with your proposal ? Not really.

Here a quickly made proposal :

<<table

<<class  
 style = "border-bottom:1px solid #AAAAAA" width="20" align="center" 
| name = HeaderStyle   <!-- We can use later what precedes as @HeaderStyle -->
>>

<<header <!-- same syntax as <<row>> which comes just after-->
- '''Groupe A'''
| colspan="10" | style="background:#98A1B2;color:#FFFFFF"
>>

<<row    <!-- explicit name rather than ugly perl-like rubbih make it far more readable -->
- {{}}       | @HeaderStyle
- **Équipe** | @HeaderStyle | width="150" | #FOFOFO
- Pts        | @HeaderStyle
- J          | @HeaderStyle
- G          | @HeaderStyle
- N          | @HeaderStyle
- P          | @HeaderStyle
- BP         | @HeaderStyle
- BC         | @HeaderStyle
- Diff       | @HeaderStyle
>>

<<row
- {{GER football}}    | left     <!-- formatting for this cell -->
- 9
- 9
- 3                 <!-- I reuse the nice syntax of unordered list to delimit my cells instead of the ugly || -->
- 0
- 0
- 8
- 2
- +6
| center | #CCFFCC >>  <!-- formatting for the whole row at the end : content first unlike currently -->

<<row
- {{ECU football}}    | left
- 9
- 3
- 0
- 8
- 2
- +6
| center | #CCFFCC >>


<<row
- {{POL football}}    | left
- 3
- 3 	
- 3 	
- 1 	
- 0 	
- 2 	
- 2 	
- 4 	
- 2
| center | #FFBEBE >>

<<row
- {{CRC football}}    | left
- 0 	
- 3 	
- 0 	
- 0 	
- 3 	
- 3 	
- 9 	
− 6
| center | #FFBEBE >>

| noborder | nopaddling | nospacing >> <!-- formatting for the whole table at the end : content first unlike currently -->

Of course it's not a complete proposal, but you get some ideas.

I love "-" as first character of a newline only to delimit a new cell. It just looks very elegant.

Of course, sometimes, one want to write a row on one single line. We could here use your syntax

<<row2 center #FFBEBE  !! {{POL football}}  !! 3 !! 3 !! 3 !! 1 !! 0 !! 2 !! 2 !! 4 !! 2  >>

The special case where you want to insert an unordered list in a cell may be treated like this :

<<row
- 
This first cell contains an ordered list 
-- one
-- two
--- alpha
--- beta
-- three
− 
This is the second cell
and contains many paragraph

This is the second paragraph 
of the second cell
| border="1" >>

should be rendered as :

This first cell contains an ordered list one two alhpa beta three

This is the second cell and contains many paragraph This is the second paragraph of the second cell

fr:Utilisateur:Jmfayard 07:03, 7 July 2006 (UTC)

---

Some good ideas. Remember that the table proposal isn't really core to this proposal. Anyway I like what you've suggested in places. Except the current wiki2 syntax would have been:

<<table
!! Groupe A |c10|style="background:#98A1B2;color:#FFFFFF" !!
!-
!! {{}}       | style = "border-bottom:1px solid #AAAAAA" | width="20" | align="center"  !!
!! **Équipe** | style = "border-bottom:1px solid #AAAAAA" | width="20" | align="center" |width=150|#FOFOFO !!
!! Pts        | style = "border-bottom:1px solid #AAAAAA" | width="20" | align="center"  !!
!! J          | style = "border-bottom:1px solid #AAAAAA" | width="20" | align="center"  !!
!! G          | style = "border-bottom:1px solid #AAAAAA" | width="20" | align="center"  !!
!! N          | style = "border-bottom:1px solid #AAAAAA" | width="20" | align="center"  !!
!! P          | style = "border-bottom:1px solid #AAAAAA" | width="20" | align="center"  !!
!! BP         | style = "border-bottom:1px solid #AAAAAA" | width="20" | align="center"  !!
!! BC         | style = "border-bottom:1px solid #AAAAAA" | width="20" | align="center"  !!
!! Diff       | style = "border-bottom:1px solid #AAAAAA" | width="20" | align="center"  !!
!- center #CCFFCC
!! {{GER football}} |left !!
!! 9  !!
!! 9  !!
!! 3  !!
!! 0  !!
!! 0  !!
!! 8  !!
!! 2  !!
!! +6 !!
!- center #CCFFCC
!! {{ECU football}} |left !!
!! 9  !!
!! 3  !!
!! 0  !!
!! 8  !!
!! 2  !!
!! +6 !!
!- center #FFBEBE
!! {{POL football}}  |left !!
!! 3 !!
!! 3 !!
!! 3 !!
!! 1 !!
!! 0 !!
!! 2 !!
!! 2 !!
!! 4 !!
!! 2 !!
!- center #FFBEBE
!! {{CRC football}}  |left !!
!! 0 !!
!! 3 !!
!! 0 !!
!! 0 !!
!! 3 !!
!! 3 !!
!! 9 !!
!! 6 !!
|noborder|nopadding|nospacing >>

this has been interesting because i'm now noticing some further inconsistencies in the above (e.g. the way parameters work differently between cells and whole rows). nevertheless the above is just as neat (if not more) as your version, and doesn't class with unordered list syntax. --Alfakim 14:21, 7 July 2006 (UTC)

I understand that the table syntax is not core of your proposal, but it's the main headache people have with the wiki syntax. Your solution for tables is only a small variation of the current wiki syntax, which is considered by many including me to be worse that the HTML syntax (try to understand a page like http://fr.wikipedia.org/w/index.php?title=Coupe_du_monde_de_football_de_2006&action=edit&section=4 with nested tables, it's a nightmare). fr:Utilisateur:Jmfayard 82.234.17.9 14:59, 7 July 2006 (UTC)

Random jotals for a prototype syntax

I've made this section for random prototype syntaxes. Feel free to put up any crazy syntax examples to see what they look like, and then we can discuss them once put here. --151.213.235.211 20:24, 7 July 2006 (UTC)

151.213.235.211's really strange table code:

((table style="color:red;float:right"        <--Params for entire table here
((row style="background:Lime))                <--Params for the row below it
|| beans || tomatos     ||  potatos    ||                  
{{column1 style="color:firebrick"))            <----params for the entire first column
||      2 rows          ||             ||      <....rowspan of 2, followed by empty cell
|| curds ||          and||whey         ||      <--number of spaces determines padding
((cell2 style="text-align:right))        <...params for the second cell of the next row
|| Mary  || had  a      || little lamb ||
))

Meh, that looks kinda weird... but it's the only thing I could think up. discuss. --151.213.235.211 20:24, 7 July 2006 (UTC)

Yet another table layouter

Disclaimer: English isn't my primary language. So if you find grammar/spelling/stylistic-mistakes, please correct them.

I was always confused when editing wikipedia aricles with "over-formatted" tables like the one mentioned above. There was so much formatting stuff, so i couldn't find the content. In most cases i didn´t wanted to edit the style. Aditionally, a lot of users don´t understand html/css, i think, so all the code will irritate them. Another problem is the widespread expanded form, caused by long definition-terms. So i thought about a different table mark-up and here is my proposal.

Syntax

• uses the new "wikifunction" syntax with << and >>
• importing of styles instead of defining it directly with <<table|import="<stylesection-name>"
• every cell/column/row is adressable unique with <counter>
• Syntax: <keyword>_<counter|classname|all>="<(css|html|special)-keyword>:<value>;[<css|html|special-keyword>:<value>;[...]]"
• counter:1-99999 for rows; A-ZZZ for cols (i think this will fit for all tables"
• see example :)

Example

I took the football-table from above and used my syntax

<<style|name="football_tables" /* the stylesection can be stored elsewhere in the document */
table="border:0px;cellpadding:1;cellspacing:0;"
row_1="colspan:10;bgcolor:#98A1B2;color:#FFFFFF;"
row_2="bgcolor:#E4E4E4;"
col_A="color:blue;" /* for example */
cells_all="align:center;" /*wikimedia should apply this for all cells; should be overwriteable */
cells_2="border-bottom:1px solid #AAAAAA;width:20px;"  /* only one row here */
cells_B="align:left;"

class_GERECU="bgcolor:#CCFFCC;" /*optional class declaration*/
class_POLCRC="bgcolor:#FFBEBE;" /*optional*/
cell_2B="width:150px;bgcolor:#F0F0F0;align:left"
cell_3B="class:GERECU;"
cell_4B="class:GERECU;"
apply_POLCRC="to:5B 6B;" /*proposal*/
>>

<<table|import="football_tables"
*!                '''Groupe A'''                 
*| |'''Équipe'''          |Pts|J|G|N|P|BP|BC|Diff
*|1|'''{{GER football}}'''|  9|3|3|0|0| 8| 2|  +6
*|2|'''{{ECU football}}'''|  6|3|2|0|1| 5| 3|  +2
*|3|''{{POL football}}''  |  3|3|1|0|2| 2| 4|  -2
*|4|''{{CRC football}}''  |  0|3|0|0|3| 3| 9|  -6
>>

expanded form:

 
<<style|name="new_football_tables"|import="football_tables"
 cell_6B="bgcolor:#FFFFFF" /*example*/
>>
<<table|import="new_football_tables"

*! '''Groupe A'''

*| 
|'''Équipe'''
|Pts
|J
|G
|N
|P
|BP
|BC
|Diff

*|1
|'''{{GER football}}'''
|9
|3
|3
|0
|0
|8
|2
|+6

*|2
|'''{{ECU football}}'''
|6
|3
|2
|0
|1
|5
|3
|+2

*|3
|''{{POL football}}''
|3
|3
|1
|0
|2
|2
|4
|-2

*|4
|''{{CRC football}}''
|0
|3
|0
|0
|3
|3
|9
|-6
>>

(Dis-)Advantages

Advantages

• It divides content from style.
• code remains clear (initially aim)
• It has the same syntax, expanded and collapsed (new row is "\n*|" or "\n*!")
• It also has the possibility to source out the style-wikifunction at the bottom of the document
• classdefinition possible
• cell-definition per row/column
• In my opinion cleaner new rows (no conflict with lists when they are made with "-")
• difference between header an regular cells

Disadvantages:

• it mixes html with css and some new definitions. I don´t think that is a *real* problem, because this is the wiki-syntax and the wiki-syntax shoud be easy and clear.
• maybe higher cpu/mem load, because it can no longer be parsed by search&replace. (i don't know how the wikimedia software handles this right now)
• problems when introducing new rows/cols at the beginning. it won't be such a big effort either. Names could solve the problem.
• problems with really big tables ( could also be solved with names or classes, bit it will mess up the table-code )
• difficult to write the scriptcode, i think

Comments

Please tell me your opinion about the mark-up, i'm very interested in them. --85.25.122.165 21:17, 17 September 2006 (UTC)

Bulleting proposal

Use ')' to denote a bulleted line, '>' to denote going down one level, '*' to denote bullets, '#' to denote numbering, 'a' to denote lettering, 'i' and 'I' to denote roman numerals, '.' to denote a period, extra ')' to denote parentheses in the bulleting.

'*', '#', 'a', 'i', and 'I' can be used in place of '-' to force its appearance in the bullet.

Example:

*) Bullet
-#) Numbered
-#) Numbered
-#) Numbered
--a) Lettered
--a) Lettered
*) Bullet
-#) Numbered
--#) Sub-numbered
---i) Roman-numbered
----I)) Roman-numbered
----I)) Roman-numbered
---i) Roman-numbered
---i.I) Roman-numbered
---i.I) Roman-numbered

• Bullet
  1. Numbered
  2. Numbered
  3. Numbered
     1. Lettered
     2. Lettered
• Bullet
  1. Numbered
     1. Sub-numbered
        1. Roman-numbered

           I) Roman-numbered

           II) Roman-numbered

        2. Roman-numbered

           ii.I. Roman-numbered

           ii.II. Roman-numbered

-- Newhoggy 10:14, 8 October 2006 (UTC)

Although this allows for more options, it's just not intuitive or easy. And we really don't want people to start using roman numerals to make lists in wikipedia articles. --Alfakim 01:35, 5 November 2006 (UTC)

Bullets vs bold by hugging

To decide whether * means bullet, or bold, or just plane asterisk, I think we should apply a hugging test. If the asterisk begins a line and has a space on the right then it is a bullet:

* Bullet level 1
** Bullet level 2

• Bullet level 1
  • Bullet level 2

If the asterisk hugs the left of a word, then it is the start of a bold tag:

only the last part of this line *is bold

only the last part of this line is bold

If the asterisk hugs the right of a word, then it is the end of a bold tag:

this line is bold* only at the beginning

this line is bold only at the beginning

Beginning and close the asterisk tag does the intuitive thing even if they don't match:

no bold *bold *bold bold* bold

no bold bold bold bold bold

Every other case, the asterisk is just an asterisk

this line * has two*asterisks.

this line * has two*asterisks.

Putting it together we have a bulleted bold line with an asterisk in the middle:

* *this bullet * point is bold*

• this bullet * point is bold

-- Newhoggy 12:08, 26 October 2006 (UTC)

This is needlessly pernickety. No new user will ever get it right. AVOID doubling tags. --Alfakim 01:34, 5 November 2006 (UTC)