Nicolas Weeger wrote: Yay! Well, it would make sense to make use of this for Wikimania: we're planning a developers hackathon before the main convention and if somebody's missing a laptop it could come in rather handy. If nobody needs direct use of it, we could reserve it for infrastructure / use by the NIC. After Wikimania it'll need to go somewhere.... ? (I've got a lovely laptop already, so I disclaim any technolust for it.) Dunno what to do with this... That could be fun. :) -- brion vibber (brion @ pobox.com)

Brion doesn't seem to think much of it but I think it's very useful, there are some people involved in development (including myself) who haven't got things like a box on a static IP address to demonstrate changes in MW to others. If there's shell access it has alot of other potential uses such as running a public SQL query service on a database dump which has been requested for some time now.

Nicolas Weeger wrote: Ok, consensus among core devs is that the laptop will go to Tim Starling, who's put in so much excellent work on the system over the last year or two (especially in our database load balancing support, text block compression, and other vital areas) and so far is laptopless. Tim will be using it for the hackathon and taking it home after Wikimania. -- brion vibber (brion @ pobox.com)

So should we kindly refuse the offer? What about a test site? Meaning? :) You want to be subscribed? What to do with the 3 other? Nicolas Weeger

What's the current status of those two? Have they been accepted? And what are they about exactly? (see my previous request about translation).

Comments: * I like the \\ for forcing a newline * I think four hyphens, no more, no less, should translate to <hr/> (i realise your proposal is not different from current syntax) * I don't like that your image syntax is like <<image foo.png>> instead of <<image:foo.png>>, this is inconsistant with the rest of the syntax. * I'd like «« an »» better than << and >> * I like the syntax for **boldface text**, //italic text//, $$typewriter text$$, ^^superscript^^, and __subscript__.

On 10/06/05, Lee Daniel Crocker &lt;lee(a)piclab.com&gt; wrote: This started off as a few quick comments, but grew as I thought; I hope it proves constructive... * In general, I like these suggestions more than I thought I would, particularly the "generic inclusion syntax"; although whether it would appeal in the same way to non-technical users I'm not sure. One major problem I see with such a text-heavy syntax is localisation - French users *will* be put off if they have to type "begin include". Obviously, we have this already to some extent, but this syntax feels much more verbose - "{{}}" doesn't need translations. In order to allow multiple languages to exist on one site, it would probably become essential to be able to map the entire wikitext of an article into a different syntax-dialect (e.g. "<<begin ...>>" -> "<<commence ...>>") on demand. * I'm not 100% sure about external links using "|" as a separator (you don't have an example of this, but you imply it) - because they can be quite long and include all sorts of characters, it might not be clear at a glance where the URL ends and the text begins: [[http://mail.wikimedia.org/pipermail/wikitech-l/2005-June/030155.html|wikite… post about Lee's syntax]] vs [http://mail.wikimedia.org/pipermail/wikitech-l/2005-June/030155.html wikitech-l post about Lee's syntax] (Obviously, with a page link, the opposite problem arises - because the page name can include " ", you can't say [[a page and its target]] and know how to split it.) I'm not saying I'm desperately married to the current syntaxes, but I do think there's a certain logic to having URLs terminated with a space. * your omission of any keyword or character to reference built-in variables seems odd - <<servername>> looks like it should mean "invoke extension 'servername' with no input". I think <<global servername>> or <<$$servername>> would be more consistent with your other syntax. * come to that, why do template parameters ("<<$foo>>") get to be less verbose than everything else? Consistency would demand "<<param foo>>", whereas simplifying most common usage would probably lead to something like "<<+foo>>" instead of "<<include foo>>". I suspect you've been swayed by programming experience here - it's "obvious" to you that "$" means "variable", so why invent something new? But in doing so you've over-ridden what was clearly a design goal of not having lots of "magic characters"; for better or worse, that avoidance is the feature that comes out most strongly - verbosity in place of arcanity, I guess. * I also like your elimination of all HTML and HTML-like elements - as you say, this will avoid confusion about people adding things in ad hoc, although incorporating references to CSS may bring on a whole new plague * I note that your image syntax sticks with the current kinds of argument (although a cryptic note implies that some of these will relate to styles in some way); it occurs to me that things like "frame" and "left", being neither named nor position-dependent, aren't consistent with everything else. Perhaps "align=left" and "style=frame"? [I guess what they imply is "frame=true" and "left=true", but this isn't how, say, "<<include foo left thumb>>" would interpret its arguments] Right, I'll stop there, and probably find that other people have made the same points more eloquently already. Ah well... -- Rowan Collins BSc [IMSoP]

Lee Daniel Crocker &lt;lee(a)piclab.com&gt; wrote: This is extremely interesting, especially because I've been working on a markup language called Kolophon that looks surprisingly similar, especially in the common text formatting sequences. One of the differences in it is that \\ is a null sequence, which you can stick inside sequences that would otherwise be considered tokens: **bold** would show up bold, but *\\*not*\\* wouldn't. (Because all tokens in it involve at least two characters--a newline and a star for bullets, for example--the addition of a null sequence allows for a universal escaping mechanism.) You seem to be using \\ for something else, but the concept might still apply. Kolophon in summary: Formatting: **bold** //italic// __cite__ ==strike== ``code`` ""unformatted"" Hyperlink: [[http://www.google.com||Link]] Transclude: {{Image:Foo.gif||caption}} Bi-relate: <<Category:films>> \\ null sequence (used to break up tokens) $$ident variable || attribute separator Line styles (at the beginning of a line): * bullet # number ; term : definition ` code ? attributes for following paragraph ! table header | table cell - table row Headings: = 1 == 2 === 3 ==== 4 Special characters: &+ &amp; &-- &mdash; &- &ndash; &| \ &^ <br /> &`` &lquot; &'' &rquot; &` &lsquo; &' &rsquo; &<< &laquo; &>> &raquo; &<- &larr; &-> &rarr; -- Brent 'Dax' Royal-Gordon &lt;brent(a)brentdax.com&gt; Perl and Parrot hacker

On Sat, 2005-06-11 at 00:49 +0200, Marco Krohn wrote: Isn't it that way already? Did I mistype something? You guys will have to explain this to me--how is it inconsistent? I don't use ":"s for any of the other extensions, just a keyword, a space, and arguments. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/> <http://creativecommons.org/licenses/publicdomain/>

On Saturday 11 June 2005 05:10, Lee Daniel Crocker wrote: I was asking because the fourth part of the "Links" section ("The text of the link can be different from the target title...") gives no example for http. sorry, my fault of course Rowans argument is right. What are chances that we change the current mediawiki syntax to yours? ;-) best regards, Marco

On Sat, 2005-06-11 at 10:59 +0200, Marco Krohn wrote: Certainly not anytime soon. This is just the first step; now I formalize it into something like a real spec, then write some proof-of-concept code, then write and test conversion code, etc. ...and now I've got this unit conversion thing to think about...:) -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/> <http://creativecommons.org/licenses/publicdomain/>

On 6/11/05, Dori &lt;slowpoke(a)gmail.com&gt; wrote: Addendum, I forgot about MetaData, which is the best part about the changes. 13) I *really* like separating out the meta data from the article. This would include things like stub messages, styles for the whole article, categories, various tags being added to articles (e.g. {{cleanup}} which seriously infuriate me as it does the opposite of cleaning up the article). I don't think considering redirects as meta data would be a good idea though. I like that the redirect is its own entity. How would the redirect work, while at the same time allowing people to go and create an article for that title later on?

I could go either way; the thing that tipped the scale for me was that using curlies for this will make the "math" extension difficult to use. I'm not real fond of them either, but you might have a user mutiny on that one. I just wanted the argument syntax to be the same for extensions, links, and such. That's a little harder to parse, and doesn't seem any simpler to me (although it's a bit easier to type). Like all extensions, it ends at >>. Styles aren't just about a new way to do boldface and such (it just happens to do that as well--can't be avoided). It's about finally getting rid of all HTML markup, and making it possible for users to edit the text of an article without having to muck with all the style data that power users have put in; it also enables shared styles for multiple pages. The big example is something like the taxonomy table on the right side of species articles. It's nothing but template inclusions, and those templates are mostly markup. Even I would have a hard time adding a line of text somewhere in that box if I thought it was needed. With the new syntax, the table could be in a template or in the text itself, with a style tag pointing to a sheet that does most of the cosmetic stuff--and which is shared by all similar articles, but the wikitext itself would be mostly content easier to edit. The separation of content and style is a BIG win-win, and has to happen in one form or another. I've settled on using CSS as is because typically the folks who want fancy styles are the power users who are used to CSS anyway. They must be nested properly, but you can always use {{end bigtable}} if you need to clarify, because comments are accepted there. Most of them don't need to be terminated explicity anyway--that was an ease-of-use thing I really wanted. It's only superscript and subscript I do that way, and I could be convinced to eliminate that shortcut. What I mean is that they aren't used for markup--they are just passed on as plain text, so that, for example, &lt;&lt; does not cause the parser to start an extension, it just puts two less-than signs into the text. Thanks for the feedback! -- Lee Daniel Crocker &lt;lee(a)piclab.com&gt; <http://creativecommons.org/licenses/publicdomain/>

On Sat, 2005-06-11 at 15:24 +0000, Ævar Arnfjörð Bjarmason wrote: The syntax only says that you can have five levels; the highest of these is "==" (I don't want to have any single-character markup). There's nothing that says you can't make "==" headings look identical to (or even bigger than) H1s with styles. I might even have a piece of metadata that says "move all headings on this page up one level". Paragraphs inside list items are not part of my content model, though perhaps they should be. You can achieve line breaks with \\. I could be convinced either way, but if we want paragraphs inside list items, we'll have to come up with a syntax for it--perhaps \\ on a line by itself could mean that. There's nothing that says the parser can't treat ":"s without a ";" differently, and render them as paragraphs with an intend style instead of actual DLs. This is a rare concession to current use; I don't like it much either, but I think most people generally do. That's another coming spec--I assure you, it will be possible to have article titles with absolutely any combination of Unicode characters, although some may be a little tricky to work with. And it keeps the syntax consistent with extensions and such. I like the idea of comments on variable lines. Just use "caption=You can...with caption&x3D;foo" I considered <<! This is a comment>> as well, but why add the character just to make it look more like HTML? The "noname" extension seemed like a reasonably understandable thing to do. I thought about that, and I don't think it's a big problem, because the only ambiguity arises when we're already inside a list (a line beginning with ** outside a list is clearly boldface, because you can't start nesting at level two). A line beginning with "**" inside a list is either a nested list item, or a boldface word at the start of an input line folded into the list item above. The ways to resolve that include just always making it mean a new list item and taking care not to put bold words there (they can always be avoided), or counting the **s on the line and making it a list item if there's an odd number (a bit magical, but I'm not terribly worried about rare cases like that). -- Lee Daniel Crocker &lt;lee(a)piclab.com&gt; <http://creativecommons.org/licenses/publicdomain/>

Tomasz Wegrzanowski wrote: HTML < XHTML 2.0 provides only six levels of headings; our existing syntax, inherited from UseModWiki, directly maps each given ={1,6} to <h1>..<h6>. The first level is reserved by MediaWiki for the page itself. We could do additional levels by using different elements for headings beyond <h6> in our HTML output, if we really needed to, but we don't support those now and I doubt there's much reason to add them. Manually adding level-1 headings is deprecated already, but we let the current parser accept them as a stop-gap measure so that existing ones could be fixed up without breaking in the meantime. (IIRC, on the request of pl.wikipedia folks.) A side note: XHTML 2.0 will introduce a new abstraction for headers based on nested <section>s, each of which can contain a <h>, to arbitrary depth: http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.5. I'm not sure if that's a model we might want to consider; that kind of large-scale nesting doesn't really map well to the wiki model, which favors line-based chunks. -- brion vibber (brion @ pobox.com)

1) I noticed you kept the "space for preformatted text" syntax. I think this is one of the single biggest causes of confusion, as it's quite easy to type: One line .. Another line .. That is, to accidentally insert a space between two paragraphs. The output will look weird, you look at your source text, but you don't see what the cause is, as spaces are invisible. Unless you know about this particular bit of syntax and understand its purpose, you will likely leave the text as it is and hope someone else fixes it. I've seen quite a few decent articles where people made this mistake, but left it in -- though it's quite visually obvious in the output, it's non-trivial to fix. My guess is that if we did a survey, we would find that the large majority of users don't know that this syntax exists. In my opinion, the leading space is not a big enough time saver to justify keeping it (particularly since it scales very badly-- preformatting two lines like that is easy, preformatting 100 is a PITA without search & replace). 2) Why not think about some alternative link patterns? I've personally always thought that double underscores might be cool. Compare: During the reign of [[Charles I of Spain|Charles I]], who inherited the throne from his father Philip, '''Habsburg Spain''' controlled territory ranging from [[Argentina]] to the [[Netherlands]], and was among [[Europe]]'s greatest powers. For this reason, this period of Spanish history has also been referred to as the "Age of Expansion." Although usually associated with its role in the history of [[Central Europe]], the [[Habsburg]] family extended its realm into [[Spain]] from [[1516]] to [[1700]]. Under Habsburg rule, Spain reached the zenith of its influence and power, but also began its slow decline. vs. During the reign of __Charles I of Spain|Charles I__, who inherited the throne from his father Philip, '''Habsburg Spain''' controlled territory ranging from __Argentina__ to the __Netherlands__, and was among __Europe__'s greatest powers. For this reason, this period of Spanish history has also been referred to as the "Age of Expansion." Although usually associated with its role in the history of __Central Europe__, the __Habsburg__ family extended its realm into __Spain__ from __1516__ to __1700__. Under Habsburg rule, Spain reached the zenith of its influence and power, but also began its slow decline. The benefit of __ is that it makes the text look underlined, which is an intuitive visual hint to hyperlinks--not to mention that having the opening and closing characters be identical makes it quite a lot faster to create links. (On German keyboards, underscores are also much easier to type than square brackets, but that's probably not the case everywhere.) 2a) You suggest supporting [[target=foo|text=bar]] as a more descriptive way of linking. However, I think [[foo<=bar]] or [[foo=>bar]] would be a more visually intuitive way to indicate the text/target distinction that does not require the use of keywords (it could, however, exist alongside that syntax, particularly with your title attribute and perhaps other link attributes that we might want to support, such as semantic information). 3) The template syntax needs to be shorter, since it's ubiquituous. People are not going to like having to type <<include NPOV>> where they previously could type {{NPOV}}. If you're trying to make templates easier to understand -- the biggest usability issue is not that people don't understand that templates are transclusions, it's that the content of "NPOV" is in the Template: namespace, but other than in the list of templates at the bottom of the editing screen, there's no reference to that namespace. I think that this is best addressed on the UI level, though. My suggested shorthand for inclusions would be <<"stub">>, <<"NPOV">>, etc. 4) We generally have to be careful with hiding namespaces from users. <<image file:xyz.jpg>> may be better than <<image file=xyz.jpg>> or <<image xyz.jpg>> because it preserves the visibility of the namespace. 5) The style syntax, I think, is the biggest problem area of your proposal. I would actually prefer it to be taken out completely at this point and developed separately, as it is also a significant new feature with major implications. The main syntax-related problems I have with it: a) This {{i may be {{b}}nested, as long}} reads horrible. Having styles separated from words with spaces makes them look like words. They are markup syntax, hence must be clearly visually distinct from the content they describe. I think the problem is exacerbated by shortcuts like {{i}}this, where the scope of the tag is not intuitively clear, which may make it look like it's not a tag at all. I don't really see this shortcut as particularly useful either, as all frequently used styles should have symbolix shortcuts anyway.. How could it be made simpler? An XML-like syntax might be the most appropriate here: <red box>Warning!</red box>. b) Using {{..}} creates *huge* transitional issues. Like it or not, templates are deeply rooted into Wikipedia, and changing the function of curly braces to something completely different will confuse the hell out of many users who use that syntax every day. c) In any case, curly braces are ugly and programmer-like. I'd much prefer to get rid of them completely in our syntax. There are other objections I have to using stylesheets, but as I said, I'd prefer to discuss this topic separately from the syntax. All in all, however, this is an excellent proposal with a lot of potential. Transitioning to a new syntax will be painful, but the wiki-users of tomorrow would greatly benefit from the added consistency, not to mention that it will allow us to move towards standardization across wiki engines as well. Before this is finalized, hopefully we can also get some input from non-MediaWiki developers to find out what other features we may want the syntax to support. Best, Erik

On 2005-06-10, Lee Daniel Crocker wrote: What about this idea for user preference displays (dates and possibly units or other items in the future). Terms which can be marked up for user preference display is done with ((term)). I don't care about exact syntax, this is just an example. If it should be linked, the syntax becomes ([term]). This would allow dates, units, etc. to be shown according to user preferences without always having to appear in link form. For those who still wish to use link form, the syntax is still just as short: ([January 1, 2000]) to link [[January 1]], [[2000]] ((January 1, 2000)) for date format without links Which would get linked the same way it currently is for [[January 1]], [[2000]]. Similarly, if people are in favor of an automatic unit converter, it could be represented as: ((3 ft)) for a plain conversion ([3 ft]) for a conversion + link to 1 E0 m Matt

On Sun, 2005-06-12 at 04:57 +0200, Erik Moeller wrote: Actually, in the formal syntax I do fix this; spaces and tabs as the end of input lines are removed, and /not/ interpreted. What looks like an empty line /is/ an empty line, so no invisible PRE section gets created. I like it, but I'm not sure we could sell that one. Personaly, I think they /should/ be a little more difficult to discourage their use, but I'm sure that opinion isn't shared by everyone. Hmm. Not sure I see that as a big issue, but I'll think about it. That's really not an argument that sways me. No matter how many users there are now, /most/ Wikipedia users are in the future, and we owe it to them to make the most usable system we can, even at the expense of present users. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/> <http://creativecommons.org/licenses/publicdomain/>

On Sun, 2005-06-12 at 04:57 +0200, Erik Moeller wrote: I agree it looks bad, so let's consider some alternatives (I've separated this into a separate thread). We need some way to tag a short span of text with either a unique ID or a non-unique class. The current proposal uses the alpha/numeric separation to do this. We could use just numbers, and tag them with a special character: {{.5 may be {{#7 nested}}, as long}} (The "." and "#" are used by CSS) But that makes it difficult to have built-in styles with understandable names. Another possibility is to put the ID between the braces: {i{ may be {b{ nested}}, as long}} This separates them from the words a little, but might make parsing a bit trickier. I definitely don't want to change the methods of marking big blocks--that is, using begin/end consistent with other parts of the syntax, and having a lone {{style}} on a line mark the following block. I hate having long-range bracketing--programmers are used to it, but new users are much more comfortable with "tag this next thing", or having the big brackets /very/ clearly marked. FWIW, I imagine that these will not be used often enough to be a big problem, because most of what needs to be done can be done with the symbolic shortcuts. But the full capability needs to get there somehow for those special cases. Any other ideas? -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/> <http://creativecommons.org/licenses/publicdomain/>

Hi, Le Sunday 12 June 2005 09:47, Ray Saintonge a écrit : As you mention Wikisource, there is a need for a syntax for texts in verse. Something like <verse> foo bar </verse> which would replace foo<br> bar<br> <br> is fine for a few line, it is NOT usable for books. Yann -- http://www.non-violence.org/ | Site collaboratif sur la non-violence http://www.forget-me.net/ | Alternatives sur le Net http://fr.wikipedia.org/ | Encyclopédie libre http://www.forget-me.net/pro/ | Formations et services Linux

On 11/06/05, Lee Daniel Crocker &lt;lee(a)piclab.com&gt; wrote: I'm a bit sceptical about having a "null" extension, too - the main problem being that it is an example of "significant whitespace", something you rightly (imho) rejected for pre-formatted text. "<< image foo >>" looks too much like "<<image foo>> for my liking, so having one be an image and the other a comment seems unwise. (I'm not necessarily suggesting that "<< image foo >>" should include an image, but having it visibly pass through as invalid would probably be preferable to having it "vanish". Having *something* explicit for saying "this is a comment" would therefore be a good idea. Whether to use "<<comment foo>>" or "<<!foo>>", or something else, touches on a larger question I already made about whether to go with words or symbols to denote what "class" of inclusion is taking place. As in, would "<<include foo>>" be better off as "<<+foo>>", etc. I think such a carefully designed syntax should consider carefully which approach to take (or exactly how to mix them), and to try and clarify my thoughts, I've made a table with examples and comments, and placed at http://meta.wikimedia.org/wiki/User:IMSoP/ext-markup [I wanted to use wiki-markup :p] -- Rowan Collins BSc [IMSoP]

Regarding image syntax, would it be possible to allow an image to be a link elsewhere, but if not specified defaults to its image description page? On the main page, [1] could link to [2], which is the logical intention of that image being a link. Another example would be the Wikiproject Spoken WIkipedia sound icon [3]. That image, and others like it, aren't intended to draw you to the images page, but rather the project page instead. I think when you click on it you initially expect to be taken there, too. [1] http://upload.wikimedia.org/wikipedia/en/5/5c/Other-langs2.png [2] http://en.wikipedia.org/wiki/Main_Page#lang [3] http://en.wikipedia.org/wiki/Image:Loudspeaker.png /Alterego

Lee Daniel Crocker wrote: [snip] Well, to be consistent with other stuff consider: {{i|may be {{b|nested}}, as long}} Humans may of course use extra whitespace for readability: {{i| may be {{b| nested}}, as long}} However I'll chime in on not being too thrilled about using curly braces for this; co-opting our current syntax to do something totally different is troublesome in a way that replacing old things with different new things isn't. Not necessarily a killer; actually you could use the above syntax exactly to produce things that look sort of like styles now, minus nesting etc. Put in [[Template:i]] "<i>{{{1}}}</i>" ... :) -- brion vibber (brion @ pobox.com)

On Mon, 2005-06-13 at 22:48 -0700, Brion Vibber wrote: TeX uses curlies, so something like a continued fraction will have two close-braces, confusing the parser: x = a_0 + \cfrac{1}{a_1 + \cfrac{1}{a_2 + \cfrac{1}{a_3+\,\cdots}}} (This is the first equation in the article "continued fraction". -- Lee Daniel Crocker &lt;lee(a)piclab.com&gt; <http://creativecommons.org/licenses/publicdomain/>

Extensions within extensions don't seem to be parsing. <ext1>Do something <ext2>And something else</ext2></ext1> Is there a way to get the inner extension to parse correctly? Thanks - MHart

Rendering wikitext is not a problem: function renderHideShow( $input ) { global $wgParser, $wgUser, $wgTitle; $parserOptions = ParserOptions::newFromUser( $wgUser ); $parser = & new Parser(); $output = & $parser->parse($input, $wgTitle, $parserOptions); Now $output->getText(); has properly rendered wikitext. So if I have: <hideshow>Here's some [[wikitext]]</hideshow> the [[wikitext]] will be properly rendered as a link. However, even though I sent the $input through the parser, AND the first parsing function called in that routine is: $text = $this->strip( $text, $this->mStripState ); which contains the foreach to render extensions, there's something that isn't quite setup properly in the parser - because the foreach never executes when extension tags are included in $input. So if $input is "Here's some [[wikitext]] and another <ext>extension</ext>", then [[wikitext]] gets rendered, but <ext> does not. Maybe its a bug... - MHart ----- Original Message ----- From: "Rowan Collins" &lt;rowan.collins(a)gmail.com&gt; To: "Wikimedia developers" &lt;wikitech-l(a)wikimedia.org&gt; Sent: Tuesday, June 14, 2005 12:45 PM Subject: Re: [Wikitech-l] Cascading extensions On 14/06/05, MHart &lt;wiki(a)matthart.com&gt; wrote: Extensions return HTML, not wikitext; that is, nothing returned by your extension function will be touched by the parser. In the case of "<e1><e2>foo</e2></e1>" only the extension for "e1" will be called, the rest is just its input, and its output is just HTML. For how to manually parse some text inside the extension, see http://meta.wikimedia.org/wiki/MediaWiki_extensions_FAQ#How_do_I_render_wik… For something more specific, you'll have to improvise. -- Rowan Collins BSc [IMSoP] _______________________________________________ Wikitech-l mailing list Wikitech-l(a)wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

On 13/06/05, Brian &lt;reflection(a)gmail.com&gt; wrote: See http://bugzilla.wikimedia.org/show_bug.cgi?id=539 This seems best placed as a new option, along with all the existing "width=foo" etc, so doesn't really require anything particularly radical as such. It's just that the code is pretty messy and I gave up modifying it and started trying to rewrite it completely. -- Rowan Collins BSc [IMSoP]

On 6/14/05, MHart &lt;wiki(a)matthart.com&gt; wrote: Maybe '@', what happens with deeper levels?

(resurrecting the thread after some days) AFAIK, nothing was decided for those 2 prizes. The hosting offer, I don't know more than what is written on the page (but again i can contact the company to have details). I'm pretty sure you can host MediaWiki on it, though :) DirectionPHP is a magazine on PHP, in french. Nicolas Weeger

I don't know, that's why i'm asking there :) It obviously has MySQL/PHP. I'm gonna ask for more info, though. Nicolas Weeger

John Ky wrote: URLs are 'pre-formatted'. Any special characters in them are already escaped as hex codes by the provider of the URL before we see it. A '?' character in a URL has a particular meaning: it separates the path portion from the query-string portion. The URL is maintained exactly, and the '?' continues to be a '?'. It is not changed, because the URL is already a URL. Wiki links are not pre-formatted; they give a page title, which is validated, parsed, and converted to a URL for a page on some particular known wiki site. Special URL characters in a title, and UTF-8 bytes of non-ASCII characters in a title, are escaped internally in the wiki when a URL for that page title is created. A '?' in a wiki page title has no special meaning, it is just another character in the title. When a URL is created for the page, the '?' in the title is encoded as %3F. In URLs '?' means one thing, in wiki page titles '?' means something else. That would of course not change just because two there are brackets instead of one on some URL links. -- brion vibber (brion @ pobox.com)