Nicolas Weeger wrote:

...

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.... ?

Ok, I'll keep it stored under my bed, and bring it to Wikimania. I may test it to make sure it works, but that's all.

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)

...

• an hosting offer "pack premium", description at

http://nexenservices.com/product_info.php?set_lang=en&cPath=2&produc...

.Once again, i guess you decide whether to accept it or not, what to do with it. I think the offer is for one year (but i can contact someone to make sure, or have more details)

Dunno what to do with this...

So should we kindly refuse the offer? What about a test site?

...

• 4 subscriptions to DirectionPHP (

http://www.directionphp.biz/a_la_une.php ).

That could be fun. :)

Meaning? :) You want to be subscribed? What to do with the 3 other?

-- brion vibber (brion @ pobox.com)

Nicolas Weeger

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, Marco Krohn marco.krohn@gmx.de wrote:

The idea about "links with a pipe character with no text" is good and saves quite a lot of typing.

Note that this is already in MediaWiki's syntax, as an odd piece of voodoo replaced at save-time. Presumably in the proposed syntax it would be valid in the saved source and thus more visible to new users. [The other big example we have of such voodoo is the "~~~~" signatures; but I guess they'll always be an invisible software feature]

...

• 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 don't think it is - if you look, the suggested syntax consists of "<<", the type of inclusion, a space, zero or more arguments, and ">>". In this case, the type of inclusion is "image" and the first argument is "name of the image". In current MediaWiki syntax, it's not clear whether "Image:" is part of the syntax (a "link type") or just part of the first argument to the generic internal link syntax (the namespace forming part of the target's title); in Lee's syntax, it's very clear which is which.

...

• I'd like «« an »» better than << and >>

« is hard to type as my (german) keyboard has no easy way of accessing these characters.

Strongly agree; I don't know how much research Lee's done into which characters are easily accessible on the most keyboard layouts (he comments somewhere that he didn't use { and } for precisely that reason), but I doubt « and » would fall into that category, as most languages have no use for such characters. (AFAIK - anyway, neither British nor US English have such characters at all, so that's an awful lot of users you'd be annoying)

On Saturday 11 June 2005 05:10, Lee Daniel Crocker wrote:

On Sat, 2005-06-11 at 00:49 +0200, Marco Krohn wrote:

...

I like the proposal and in particular that internal / external links are handled more consistently - good work! Is it possible to use the pipe character "|" or external links as well, e.g.

[[http://piclab.com%7CPiclab]]

Isn't it that way already? Did I mistype something?

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.

...

...

• 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.

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.

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 Fri, 2005-06-10 at 21:22 +0000, Ævar Arnfjörð Bjarmason wrote:

• 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.

Hmm, not sure what you mean--I did it that way precisely because it's consistent with all the other extensions, and style tags.

On Sat, 2005-06-11 at 00:54 +0100, Rowan Collins wrote:

• 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:

You're right, I don't have an explicit example, but it was my intent. If you want to have URLs with "|" (pretty rare, I think), you'll have to encode that character, just as we would with spaces now.

• 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.

Yes, each variable is like an extension of its own, and some of them *will* have arguments, for example <<currentmonth tc gen>> when you want the name of the current month, in titlecase and genitive.

• 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>>".

The $ things are for parameter expansions *inside* the template, not for invocations of a template, so they're just like variables. I think "$" is just as evocative as "param", and easier to type, especially in the three-way fallback syntax. I wouldn't mind simplifying some of the other ones like "include" or "raw" down to a special character, especially in light of you're good point about internationalization.

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.

True, I am swayed by programming experience, but I'm not so concerned with having many special characters, as long as they have some overall sane structure to them--that's why "$$" is used for <tt>, for example; it evokes the idea of "variable" there as well. Simplicity is a goal, but not number one; this is simpler than the existing syntax, but not simpler than needed to achieve goal number one, ***ease of editing**.

• 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]

The details here are yet to be worked out. It is my intent that each extension interpret its arguments its own way, so the arguments to image will be only those meaningful to it, and not include *purely* stylistic things, except maybe as shortcuts. Again, I'm wiling to sacrifice a little bit of simplicity and/or consistency for ease of use.

This is more in line with what I'd personally come up with than the existing syntax, but it's very different from what the hundreds of current MediaWiki users expect. I personally dislike "\" for line breaks, as I'd expect a literal \ or \ instead, but that's a relatively minor point overall.

I'm naturally opposed to any non-ASCII markup, for obvious reasons, but from an idealistic perspective this isn't a bad start.

-- Austin

On 6/11/05, Dori slowpoke@gmail.com wrote:

Some questons/comments/concerns:

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?

First of all, forget about my comment regarding «« and »», I was under the impression that they were common on most keyboard layouts but they apperently aren't, so I take that back, it's not a good idea.

I've gone over your proposal more thoroughly so here are some more detailed, comments:

* Regarding your style of headings: It's currently possible to make the html equivalent of <h[1-6]> with wikisyntax, but you specifically disallow level one (=) headings which is insufficient, remember that not everything is an article where you get the first heading generated for you, special pages and other extensions might want to make their own first heading (other than the one made with use of the title object) using wikisyntax and there will be no way for them to do that save for falling back to spitting out HTML, furthermore level one headings are in wide use on pages like the English Wikipedia's Village pump, why do you want to deprecate it? Presumably it clashes with something else I haven't noticed.

* I like that one newline no longer terminates a list, however this syntax will not be complete without allowing <p> since there will be no way to make paragraphs within a list item.

* I don't like your definition lists because they're exactly the same as the current ones and encourage using ":" for indenting, if you're going to indent something like

: Indent

<dl><dd>indent</dd></dl> is not the best way to render it, it may be legal XHTML to omit <dt> and take advantage of the fact that <dd> is indented by what would be approximately a tab in most (if not all) browsers, but it's certainly far from the way it should be done™.

* Using [[]] for external links means that in practice we won't be able to have articles/pages with titles like "http://foo" although [htp:/fo] are all legal characters in page names (not really that big a disatvangage, and I like it better than [])

* Just so we're clear you want [[stuff|like|this]] to generate (approximately) <a href="stuff" title="this">like</a>? I don't really see the point, but I suppose it doesn't hurt since it extends the previous syntax gracefully.

* I like the [[Foo (bar)|]] syntax, we currently do support that but transform it (as Rowan Collins pointed out) at savetime, however I don't see any good reason why it shouldn't be a valid part of the syntax.

* I don't like the named arguments for links, It would clash with the current namespace of links (i.e. does [[target=foo|text=bar]] point to "foo" or "target=foo" ? How about [[asdf=foo]] ? ) I think it's overdoing it, let's have one syntax for each action.

I like where you're going with the image syntax but I don't like it *quite* enough to really like it, I'll explain: What I don't like about our current image syntax is that due to the way it's all cluttered up it's hard to extend, yours is better but IMO not quite good enough, for example I'd like to have (comments begin with #):

<<begin image>> file=pl_bulet.png style=frame # instead of just "frame", no "magic words", just attributes=values width=5em caption=Logo <<end>>

Note however that since = has a special meaning caption would always have to come last if you wanted to write something like:

caption=You can make captions in MediaWiki with caption=foo

Or alternatively the parser would have to be smart about it.

* I like the whole <<>> thing, but I'm not sure about the added complexities of using it for comments too, how about <<comment like this>> (just an extension named comment that ignores its input) rather than << like this>> (i.e. to make << *.*?>> comments), or just the old <!-- -->

* I was sceptical at first about the new {{}}, but I've come to like it, any "decent" article on Wiki(pedia|media) seems to have infoboxes and other things that require some kind of inline CSS styles and eliminating all that in favor of a pure wikisyntax solution would be nice indeed.

* I like // ** ^^ $$ and __, note however that since * is used for both lists and bold the parser would have to break a case like "***foo**" down by looking for the closing ** at the end of the line to see if it's dealing with a first level <ul> or a third level <ul> (not that big a deal, we do that already in a way with ''' and '')

* Aside from the advantages of the new {{}} they're just like our current tables, except for one thing, the new ^ and < syntax, I love it, I think it's a very simple and intuative solution to the problem of colspan/rowspan not being obvious enough.

P.s. Of course the french will hate it, but that kind of given..

On Sat, 2005-06-11 at 15:24 +0000, Ævar Arnfjörð Bjarmason wrote:

...you specifically disallow level one (=) headings which is insufficient, remember that not everything is an article where you get the first heading generated for you, special pages and other extensions might want to make their own first heading...

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".

• I like that one newline no longer terminates a list, however this

syntax will not be complete without allowing <p> since there will be no way to make paragraphs within a list item.

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.

• I don't like your definition lists because they're exactly the same

as the current ones and encourage using ":" for indenting, if you're going to indent something like

: Indent

<dl><dd>indent</dd></dl> is not the best way to render it, it may be legal XHTML to omit <dt> and take advantage of the fact that <dd> is indented by what would be approximately a tab in most (if not all) browsers, but it's certainly far from the way it should be done™.

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.

• Using [[]] for external links means that in practice we won't be

able to have articles/pages with titles like "http://foo" although [htp:/fo] are all legal characters in page names (not really that big a disatvangage, and I like it better than [])

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.

• Just so we're clear you want [[stuff|like|this]] to generate

(approximately) <a href="stuff" title="this">like</a>? I don't really see the point, but I suppose it doesn't hurt since it extends the previous syntax gracefully.

And it keeps the syntax consistent with extensions and such.

I like where you're going with the image syntax but I don't like it *quite* enough to really like it, I'll explain: What I don't like about our current image syntax is that due to the way it's all cluttered up it's hard to extend, yours is better but IMO not quite good enough, for example I'd like to have (comments begin with #):

<<begin image>> file=pl_bulet.png style=frame # instead of just "frame", no "magic words", just attributes=values width=5em caption=Logo <<end>>

I like the idea of comments on variable lines.

Note however that since = has a special meaning caption would always have to come last if you wanted to write something like.

Just use "caption=You can...with caption&x3D;foo"

• I like the whole <<>> thing, but I'm not sure about the added

complexities of using it for comments too, how about <<comment like this>> (just an extension named comment that ignores its input) rather than << like this>> (i.e. to make << *.*?>> comments), or just the old

<!-- -->

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 like // ** ^^ $$ and __, note however that since * is used for

both lists and bold the parser would have to break a case like..

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).

Tomasz Wegrzanowski wrote:

On Sat, Jun 11, 2005 at 03:10:09PM -0700, Lee Daniel Crocker 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".

Do you have any particular reason to allow only 5 levels ? That breaks backwards compatibility and reduces range of allowed options for no good reason.

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)

On 2005-06-10, Lee Daniel Crocker wrote:

I decided to release my new syntax for comment before I finished the formal definition. I'd like to get opinions about it;

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 01:55 +0200, Tomasz Wegrzanowski wrote:

Do you have any particular reason to allow only 5 levels [of headings] ? That breaks backwards compatibility and reduces range of allowed options for no good reason.

Wikitexts generally end up being rendered /within/ HTML pages, and HTML has a limit of six levels anyway, so it seemed safe. But I'm not married to it. Are there really Wiki pages that use all six? I'd be surprized if any really needed even five.

On 11/06/05, Lee Daniel Crocker lee@piclab.com wrote:

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'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]

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

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

Lee Daniel Crocker wrote:

On Sun, 2005-06-12 at 04:57 +0200, Erik Moeller wrote:

...

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.

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.

A leading space can be useful for poetry in Wikisource.

...

3. The template syntax needs to be shorter, since it's ubiquituous.

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.

Indeed. The recent growth in template use can make editing far more difficult for people who are not familiar with the relevant templates.

Ec

On Sun, 2005-06-12 at 04:57 +0200, Erik Moeller wrote:

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 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?

On Mon, 2005-06-13 at 22:48 -0700, Brion Vibber wrote:

...

I really don't want to use curlies for inclusions, because it makes short equations a pain,

I'm not sure I understand why that is. Can you give an example?

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".

On 12/06/05, Erik Moeller erik_moeller@gmx.de wrote:

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.

This is something I forgot to mention - there is (or was) a bit of discussion towards a standardised WikiMarkup a while ago: * some discussion on MeatBall - http://www.usemod.com/cgi-bin/mb.pl?WikiMarkupStandard * a mailing list which seems to have died a quiet death, but to which some people might be subscribed who would be interested in Lee's proposal - http://www.freelists.org/archives/wiki/ * one result was the beginnings of a collection of existing markups - http://interwiki.sourceforge.net/wms/summary.sxc

Indeed, it seems there's lots of stuff about that might be worth "tapping into": * looking around, I found a more general "interwiki" list on which people seem to have raised these kinds of issues - http://sourceforge.net/mailarchive/forum.php?forum=interwiki-discuss * ...from which I further blundered into http://www.emacswiki.org/cw/MarkupStandardPlanB

I guess there's an almost unreadable amount of discussion "out there", but what I was really looking for was places Lee could present his ideas to non-MediaWiki folk if/when he feels they're ready.

On Mon, 2005-06-13 at 20:00 -0700, Brion Vibber wrote:

Just something to think about: for languages written right-to-left (mainly Hebrew and Arabic and other languages written in those scripts) editing wikitext with markup can get real ugly due to bidirectional text layout in the browser's text editor widget.

Among other things, the on-screen position and direction of punctuation pairs (eg [], {}, and <>) may change depending on whether surrounding text is LTR or RTL. If you're mixing Latin-script keywords and local text together, things start flipping around in interesting ways and it gets hard to tell what's what.

Where keywords are used, making sure it's possible to use localized keywords throughout the system, and being able to isolate necessary Latin keywords (such as CSS style definitions) can make a big difference in usability here.

Thanks. I admit total ignorance in this regard; I've never used a Hebrew or Arabic browser, and I can imagine that mixing texts would be a problem. I don't think being able to localize keywords would cause any problems, and if it simplifies the user experience a lot (which is, as I've said before, my #1 goal), then I'm all for it.

Of course, I'd prefer that the localizations themselves be a defined part of the standard.

On 14/06/05, MHart wiki@matthart.com wrote:

Extensions within extensions don't seem to be parsing.

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_wiki...

For something more specific, you'll have to improvise.

On 6/14/05, MHart wiki@matthart.com wrote:

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);

Using Parser::parse() is simper and usually enough for most situations, unless you want to manually manipulate the title object or something like that before parsing.

On 6/14/05, MHart wiki@matthart.com wrote:

Small hack I did today is very useful when converting help text to wiki format - I added ~ to the list elements. Is ~ used elsewhere.. looks like maybe a timezone thing so that ~~~ would fail? Is there another char that would work better?

Maybe '@', what happens with deeper levels?

Hi,

I'm not sure if this has been discussed yet, but I want to raise it just in case it hasn't.

I like the proposal to make internal and external links use the same markup because it is more consistent, but I worry about the treatment of the ? character:

In the current syntax, it appears that the internal [[]] syntax encodes the ? character so that wiki pages can have the ? character in its name. While the external [] syntax does not encode the ? character so that pages that have the ? character in the URI still work (eg. cgi pages).

So in the new syntax, is the ? encoded or not? It would be nice if it were possible for the author to force the character to be encoded or not encoded.

I recently ran into a problem where I attempted to use interwiki links to shorten URIs (some of them can be hopelessly long) only to find that when I use the [[]] syntax, the ? becomes encoded and so the URI becomes mangled and unusable. Because of this behaviour I was unable to use the interwiki links the way I intended.

I wanted to use [[cvs:dir1/dir2/file?revision=1.3]] to link to

http://cvs.something.org/really-really-really-long/cgi-bin/dir1/dir2/file?re...

but instead got:

http://cvs.something.org/really-really-really-long/cgi-bin/dir1/dir2/file%3F...

Which the cgi application couldn't accept.

So the treatment of the ? character is important because it has a special meaning.

-John

On Sat, 2005-06-25 at 11:51 -0700, Brion Vibber wrote:

...

In the current syntax, it appears that the internal [[]] syntax encodes the ? character so that wiki pages can have the ? character in its name. While the external [] syntax does not encode the ? character so that pages that have the ? character in the URI still work (eg. cgi pages).

I hadn't planned on changing that behavior, other than to more completely document it. Internal and external links are still entirely distinguishable, and there's no reason they can't have slightly different rules where convenient.

On 6/15/05, Nicolas Weeger nicolas.weeger@laposte.net wrote:

(resurrecting the thread after some days) AFAIK, nothing was decided for those 2 prizes.

Who is in the position to say yes/no on this? In any case I think it's better than nothing and I'm sure there are some uses for it.

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 :)

Having detailed info such as do we get root access? Shell access in general? The ability to install applications? What services are avalible (mysql? php? perl? .. ) would be nice, if you could contact the company and relay that info back that would be great.

DirectionPHP is a magazine on PHP, in french.

Count me out on that one;=)

Nicolas Weeger _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l