Here's another pointer: http://tikiwiki.org/tiki-index.php?page=RFCWiki

And if you look at the Internet-Draft you see the main problem. Everyone thinks that the own wiki projects syntax should become the standard :-)

On Thu, 31 Mar 2005 13:24:46 +0100, Rowan Collins rowan.collins@gmail.com wrote:

On Wed, 30 Mar 2005 20:36:40 +0100, Tomer Chachamu the.r3m0t@gmail.com wrote:

...

Use image: [[Image:Name.jpg]] Mention image: [[:Image:Name.jpg]] Use category: [[Category:People]] Mention category: [[:Category:People]]

These are nothing to do with "templates"/"transclusion", but magic

I know that. I am pointing out how the use-mention distinction was handled in cases apart from templates, i.e. differently.

kinds of link - both "Image:Name.jpg" and "Category:People" are the titles of pages to which you are creating a link, but a special kind of link because they are special kinds of pages. So, as you say, a leading colon treats them as unspecial, so there is a use/mention distinction.

Personally, I think the most "surprising" kind of link is "[[Media:...]]", because it doesn't link to any page at all. OTOH, I

That is also a problem. I would want the namespace to be called "Media", but with the translated name as "Image" for help during transition. (This is similar to the "Project" and "Wikipedia" namespaces: The first is new in an attempt to disassociate MediaWiki from Wikipedia, and "Wikipedia" is an alias on Wikipedia sites for it. You can have two names for the same namespace.)

think [[Sound:...]], [[Video:...]], or maybe a combined [[AV:...]] will end up being needed to provide the kind of integration we already offer for images, but presumably the file descriptions will remain in one namespace, so those won't be real pages either.

That's another possibility.

...

Use template: {{Box}} (not [[Template:Box]] or {{Template:Box}}) -> I can understand {{Box}} as a shorthand for {{Template:Box}} as people will rarely use namespace 0 stuff as templates, so why not {{Template:Box}} but {{:Template:Box}} ? Use template (substitution): {{subst:Box}} (no suggestions from me here, sorry) Mention template: [[Template:Box]]

"Templates", unlike "Images" and "Categories", are not a special kind of page; linking to them doesn't do anything different from linking to any other page. I guess it could have been decided that they *were*

That is exactly my point. The "Template" namespace is intended for templates, so linking to it with [[Template:Box]] is a *use* of it, not a *mention*. Mentions should be relegated to using a colon as in [[:Template:Box]] as currently with images and categories.

special, and that [[Template:Box]] would cause a transclusion (with [[:Template:Box]] for "mentionning"), but the flexibility of being able to transclude *any* page has proved useful for various cunning schemes.

Such as what? I cannot see the disadvantage to putting these pages in the Template namespace. Also, a secondary syntax could be made, like that old {{msg:}} syntax. {{msg:Box}} would include [[Box]], not [[Template:Box]].

One thing I haven't been able to decide is what the new substitution syntax would be. I was considering ~[[Template:Box]] (thinking this would be one in a set of substitutions, i.e. along with ~~~3 ~~~~4 and ~~~~~5.

As for "{{Box}}", "{{Template:Box}}" and "{{:Template:Box}}", they appear, rightly or wrongly, to all be treated equivalently by the current code. (Arguably, the 3rd is incorrect, since the leading colon is making no meaningful distinction).

I don't like the implied template namespace. {{:Box}} for the article is not exactly intuitive.

On Thu, 31 Mar 2005 17:57:38 +0100, Tomer Chachamu the.r3m0t@gmail.com wrote:

...

Personally, I think the most "surprising" kind of link is "[[Media:...]]", because it doesn't link to any page at all. OTOH, I

That is also a problem. I would want the namespace to be called "Media", but with the translated name as "Image" for help during transition.

Well, no, those do two different things - one links to the *description*, one directly to the file itself (this is what I meant by it not linking to any page at all), so [[Media:]] would not now be a good replacement for [[Image:]] as both are already in use. Looking ahead at the needs of a more multimedia-oriented scheme, one could envisage a whole set of ways of referencing the information. For instance:

* [[File:...]] could be the name of the actual description pages, so links to [[File:Foo.jpeg]] would be equivalent to [[:Image:Foo.jpeg]], and things that weren't images wouldn't seem so oddly named (you would no longer see bold headings saying "Image:Foo.ogg"). * [[Image:...]] could continue to function as at present (i.e. magic syntax with an increasing number of display options) * Similar magic syntaxes such as [[Audio:...]] or [[Sound:..]], [[Video:..]], or maybe just [[AV:...]], could generate some kind of user-selectable embedded player (I think that's discussed briefly at http://meta.wikimedia.org/wiki/Multimedia) * [[Media:...]] would be less necessary with proper sound and video markup, but would have to remain in the code for backwards compatibility. * Also for backwards compatibility, [[:Image:...]] would have to be special-cased as an alias for [[File:...]] (i.e. a link to the description page); to avoid confusion, any new "magic namespaces", such as [[Sound:..]], etc, would have to have similar "escaped" versions ([[:Sound:...]], etc)

That's quite a radical set of changes, I know, but I think it covers all the problems with the current system without breaking existing content. Of course, it makes the syntax even more "magic" and different for different cases, which is what you were suggesting we avoid. We could, I guess, store what kind of media each file is (Image / Sound / Video / other?) leaving us with only 3 distinct cases ("use" file, mention description, mention file directly) - and with good enough support for the first, the third becomes much less needed - but nothing elegant immediately comes to mind even then.

(This is similar to the "Project" and "Wikipedia" namespaces: The first is new in an attempt to disassociate MediaWiki from Wikipedia, and "Wikipedia" is an alias on Wikipedia sites for it. You can have two names for the same namespace.)

Actually, that's not quite correct. Every namespace has *exactly 2* names, one of which is "canonical" (available on every installation, regardless of configuration and language) and one which is local (varying according to content language and configuration settings). The namespace with the canonical name "Project:" has its local name set to the name of the project at installation (so, for Wikipedia sites, it is "Wikipedia:" or some local variation, such as "Vikipedio:"; for Wiktionaries, it is "Wiktionary:"). The "Project:" prefix is never actually treated as the "real" name of the page (it never appears as the heading), it's just there so you can create links without knowing the target language/configuration.

That's not to say it's *impossible* to have a redundant name built in purely for backwards compatibility, I just wanted to be clear that the software doesn't *currently* support such a thing.

That is exactly my point. The "Template" namespace is intended for templates, so linking to it with [[Template:Box]] is a *use* of it, not a *mention*. Mentions should be relegated to using a colon as in [[:Template:Box]] as currently with images and categories.

The template namespace is intended for use exclusively in inclusions, but inclusions are *not* intended exclusively for the template namespace. This is a design decision, to be sure, but it *is* one people have taken advantage of.

Such as what? I cannot see the disadvantage to putting these pages in the Template namespace.

Off the top of my head, transclusion has been used to: * create utility pages which are seperated by day or topic, but which can also be viewed as one page; the transcluded pages in this case being sub-pages of the "main" one (examples include "Votes for Deletion" and the archives of the "Wikipedia Signpost" newspaper); you _could_ put the individual parts in the Template: namespace, but this would seem forced, as they are designed to also be viewed on their own * create templates "for personal use" as sub-pages of a User: page; this is particularly useful with the substitution syntax, for things like adding a message to a User_talk: page; there are other examples like this, too, where it simply makes more sense to have them sorted with associated content, rather than "cluttering up" the global set of templates in the Template: namespace. * wrap encyclopedia articles in additional information, to create slide-show / "guided tour" sequences [e.g. "<intro><previous_link><next_link> {{:Article}} <previous_link><next_link>"]; this currently suffers from problems with inheritance of categories, interlanguage links, etc, but is an example of a use that would be not just inconvenient but completely impossible if all transclusions had to be from pages in the Template: namespace.

Also, a secondary syntax could be made, like that old {{msg:}} syntax. {{msg:Box}} would include [[Box]], not [[Template:Box]].

Surely that defeats the whole object of the exercise, which was to "rationalise" the syntax. Either inclusion requires its own syntax, so that it can reference any page, or no inclusions from non-template pages can be made; to have both at once is just asking for confusion.

One thing I haven't been able to decide is what the new substitution syntax would be. I was considering ~[[Template:Box]] (thinking this would be one in a set of substitutions, i.e. along with ~~~3 ~~~~4 and

If you were to go down that route, I would suggest something more along the lines [[~Template:Box]], because the tilde ('~') in your example doesn't look very "connected" to the link syntax. Enclosing tildes, like ~[[Template:Box]]~, might be better as well; of course, you'd have people wondering why ~[[User:IMSoP/foo]]~ didn't do anything...

I don't like the implied template namespace. {{:Box}} for the article is not exactly intuitive.

No, I agree that that is kind of confusing, but since this is currently the only thing that's special about the Template namespace, it does make sense - as you say, inclusion from the main namespace is a lot rarer. Actually, the problem is arguably the existence of a nameless namespace - I'm not suggesting we get rid of it, but the only reason {{:Box}} has to be so unintuitive is that there's nothing obvious you can put on the front to say "in the article namespace". If we were designing a wiki from scratch, with no legacy users or content, it would be worth at least considering the different design concept of every namespace being named, but links defaulting to within the *same* namespace (as though each namespace was more like a seperate wiki).

On Thu, 31 Mar 2005 22:20:37 +0100, Tomer Chachamu the.r3m0t@gmail.com wrote:

...

example doesn't look very "connected" to the link syntax. Enclosing tildes, like ~[[Template:Box]]~, might be better as well; of course, you'd have people wondering why ~[[User:IMSoP/foo]]~ didn't do anything...

No you wouldn't. The whole point of including "Template:" in the syntax is to make it really obvious how to transclude *other* namespaces.

No, you were suggesting we replace [or could have developed in the first place] the {{...}} syntax, which transcludes arbitrary pages, with a "magic link" behaviour for Template: pages. This, by definition, would limit transclusion to pages in the Template namespace (unless a completely different syntax was available in parallel, which behaved more like the current one).

The ~[[...]] substitution syntax, or so I assumed, was to go with that "magic link" system -- if you're not replacing {{...}}, why would you replace {{subst:...}}? -- and therefore that too logically only applies to [[Template:...]] pages. A feature that allowed you to *substitute* any page, but only *transclude* those in the Template namespace, would be just plain bizarre (even, indeed especially, if a completely different syntax allowed you to do the full range of transclusions)

To "make it really obvious how to transclude *other* namespaces", you'd keep exactly the syntax we have now, but remove the behaviour that makes it default to the Template namespace. That's not even a very complex change, code-wise, although it would break a hell of a lot of existing content, obviously.

Lee Daniel Crocker (lee@piclab.com) [050401 10:55]:

Forgive me if there was a big discussion of this while I was in lurker mode for the past year or so, but is it really a good idea to allow arbitrary transclusions at all? I can see the usefulness of templates overriding the problems and limiting their spread to a few cases; but arbitrarily including text that constantly changes seems like a good way to screw up things like article provenance, evaluations, and such.

At present it's used to very good effect in the Wikipedia: namespace, to make pages such as [[WP:FAC]] and [[WP:VFD]] manageable. Note that VFD actually transcludes pages largely made of transclusions.

Templates that masquerade as actual article text are considered decidedly improper - one of the earliest candidates on [[Wikipedia:Templates for deletion]] was one such - and [[Wikipedia:Template namespace]] includes the admonition "Templates should not masquerade as article content in the main article namespace; instead, place the text directly into the article." (which I wrote.)

(I have no idea of what whacky tricks people may have gotten up to on other language Wikipedias.)

So far people haven't gotten much away with egregious template abuse, and the category system has *mostly* quelled the urge to bloody ugly subject series boxes.

- d.

Tim Starling (t.starling@physics.unimelb.edu.au) [050401 18:52]:

Lee Daniel Crocker wrote:

...

Forgive me if there was a big discussion of this while I was in lurker mode for the past year or so, but is it really a good idea to allow arbitrary transclusions at all? I can see the usefulness of templates overriding the problems and limiting their spread to a few cases; but arbitrarily including text that constantly changes seems like a good way to screw up things like article provenance, evaluations, and such.

It was a bad idea. The users made me do it.

Hey, Paul T. Riddell has an FBI file for selling secrets to the Daleks.

http://web.archive.org/web/20020225052146/www.hpoo.com/columns/hells/news45....

- d.

On Apr 1, 2005 1:54 AM, Lee Daniel Crocker lee@piclab.com wrote:

Forgive me if there was a big discussion of this while I was in lurker mode for the past year or so, but is it really a good idea to allow arbitrary transclusions at all?

Well, as I and others have said, it's certainly being put to plenty of use (I gave some examples in the middle of http://mail.wikipedia.org/pipermail/wikitech-l/2005-March/028494.html). Whether this is "good" use or not is open to interpretation and debate, obviously.

Personally, I think the use on utilty pages (VfD, etc) is rather clever and makes the pages more useful - it allows the same content to be viewed in multiple ways. Obviously, that effect could be achieved by moving whole wodges of content to the Template: namespace, but that seems to me like a *worse* scenario, in that it pulls content that belongs in Project pages out of the Project namespace. [Note that, for a period just before the full template system was invented, people did exactly this, putting the discussions in the MediaWiki: namespace, to which transclusions were orginally limited]

I can, however, see your concern that this adds complexity to all sorts of things, particularly to do with reviewing, auditting - and dare I mention locking - content. All that would be true however limitted the feature was, and maybe you meant that there should be no templates at all. But the enthusiasm with which the feature was used before it was even properly implemented shows how much it's wanted in some form.

Basically, I think this comes down to a fundamental conflict within Wikipedia (and Wikimedia generally), which you could describe as between the "Wiki-" and the "-pedia" - on the one hand, the concept of a wiki is that it's simple, community-based, dynamic, etc; on the other hand, an encyclopedia should be well-presented, comprehensive, and reader-friendly. That conflict is what brought MediaWiki into being - from the need for namespaces to neatly seperate discussion and policy from articles onwards. [If one were designing with only the "Wiki-" part in mind, one probably wouldn't bother with page protection, for instance]

Add in the unprecedented *size* of Wikipedia, and templates become just another essential tool for the community to manage the content they want to present to readers. Among the diverse ways in which the template system has been used, I'm sure there would be many that you'd agree were extremely positive - templates, being, after all, a way to make management of repeated or similar content *easier*.

I think any such tool will be open to abuse, but also to positive creative use; telling the difference is a matter for the community, not the designers of the tool. I, for instance, would count as "abuse" stacks of attention boxes on one article, and templates nested so deeply and complexly that you can't work out where the actual content comes from (e.g. the calendars on en.wikipedia's date articles, which are cunning but tortuous). Neither problem can really be defined in technical terms, and some clearly feel they are valid uses, so I think the *software* is doing it's job just fine.

[Apologies for verbosity and/or tendency to rant; I do not claim this to be anything other than one opinion in a valid debate]

Magnus Manske wrote:

There's another way:

• Agree on a XML standard for wikis
• Each wiki system writes a wiki-to-XML and XML-to-wiki function

I think this doesn't resolve the main issue, which is end-user joy. What I hope to do is encourage at least a strong subset of syntax which is used universally, so that I can go to any wiki and do some basic normal things and have the result be what I want.

This has nothing to do with the separate issues of portability of wiki text, although I think that's important too.

--Jimbo

Magnus Manske wrote: <snip>

There's another way:

• Agree on a XML standard for wikis
• Each wiki system writes a wiki-to-XML and XML-to-wiki function

That's a good way to exchange between system. But do we have an XML draft already ?

Otherwise, with (n) wiki systems, *at least* (n-1) will have to make changes, if not all of them. From what I can tell, "**" is used for "bold", so any of you really want to change from "'''"? ;-)

''' and '' cause troubles when the language use ' . In french we might want to say : l'''étoile'' . Parser will bug on that one : it starts bold then start italic.

On Sun, 3 Apr 2005, David Gerard wrote:

Ashar Voultoiz (hashar@twenkill.net) [050403 07:25]:

...

Magnus Manske wrote:

...

...

Otherwise, with (n) wiki systems, *at least* (n-1) will have to make changes, if not all of them. From what I can tell, "**" is used for "bold", so any of you really want to change from "'''"? ;-)

...

''' and '' cause troubles when the language use ' . In french we might want to say : l'''étoile'' . Parser will bug on that one : it starts bold then start italic.

It's bad enough in English. You end up with either tortured syntax or tortured use of <nowiki>. Any language with apostrophes will have this problem.

The 1.4 parser seems much better on this than the previous ones, and I am removing lots of now useless <nowiki> from lots of pages in italian. Things like l'''italia'' work correctly, producing an "l", an apostrophe and a word in italics. The only cases when <nowiki> is still necessary are when there are multiple instances of ''', '' and ' on a single line and parsers gets confused.

Alfio

On Wed, 30 Mar 2005 15:17:44 -0500, Evan Prodromou evan@bad.dynu.ca wrote:

Another possibility is using a WYSIWYG in-browser editor, so that Wiki syntax becomes more or less a moot point.

If you haven't tried it already, Jim Higson's client-side WYSIWYG rendering stuff (http://81.5.150.113/wysi/) is most impressive.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Jimmy (Jimbo) Wales schrieb:

Ok, I see your point. But the right thing to do, I think, is to point out that PhpWiki syntax is wrong and outdated and nonstandard.

Concering MediaWiki, this inevitably leads to one of the following scenarios:

1. We declare MediaWiki the standard, based on the total number of pages using this standard. Call me "Bill" ;-)

2. We make our parser understand other wiki syntax *in addition* to our own. If you think our current "parser" is a mess, wait for this to happen. It won't be a standard, but a syntax swamp.

3. We change our wiki syntax, however slightly. Besides everyone using MediaWiki having to learn a new (altered) syntax, we'll have to change *every* page in our databases, including *all* old revisions. For that, we'll have to write a 100% perfect parser for the old syntax that can create 100% perfect new code. Good luck with that.

*However*, if every (major) wiki would have a wiki-to-XML and a XML-to-wiki parser (which we'll have to do anyway, in a way, for #3), *then* we could - - read our wiki text from the database for editing - - convert it on-the-fly to XML - - convert the XML to any syntax the user wants, including a yet-to-be written standard - - convert the user's input to XML on saving - - convert the XML to MediaWiki syntax for storing in the database

A nice side effect would be "wiki beautification", so no matter what mess the last newbie made with the source, it always looks nice and clean :-)

Magnus

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Lee Daniel Crocker schrieb:

On Thu, 2005-03-31 at 10:40 +0200, Magnus Manske wrote:

...

3. We change our wiki syntax, however slightly. Besides everyone

using MediaWiki having to learn a new (altered) syntax, we'll have to change *every* page in our databases, including *all* old revisions. For that, we'll have to write a 100% perfect parser for the old syntax that can create 100% perfect new code. Good luck with that.

Yep, that's the only acceptable option. You are correct that it will be difficult, but that doesn't change the fact that we have to do it that way.

In that case, maybe we should hurry getting that standard set, so we can do this when we change to MediaWiki 1.5 - it will need downtime for database conversion anyway.

It should be obvious, though, that we /don't/ want a "perfect" parser for the current syntax--we want the existing parser just as it is now, warts and all, which is what the current text is written to. That parser will have to be modified to output the new syntax when we update, and that should be perfect (and /can/ be , because it will be well-defined at that point).

Which raises another question: By converting the source, we actually edit all old and current versions of all articles. So, when I look at an old edit of mine, it willk show something different from what I wrote at the time. I know that this is *supposed* to only affect syntax, but is retrospect changing of user submissions OK with the GFDL? (After all, we're not making a new version based on an old one, like editing; we'll be changing the sumbission itself.)

Magnus

On Thu, 2005-03-31 at 11:20 +0200, Magnus Manske wrote:

I know that this is *supposed* to only affect syntax, but is retrospect changing of user submissions OK with the GFDL? (After all, we're not making a new version based on an old one, like editing; we'll be changing the sumbission itself.)

We wouldn't be changing anything; we'd just be encoding exactly the same semantic content in a different code. That's one reason why we have to do the semantic model first--otherwise, we're not sure what current wikitext means.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Axel schrieb:

Well I think you already mentioned a link to your xml format, but I didn't found it it my archives. Could you please post it again.

I don't think there's a DTD or something, but you can look at the "flexbisonparse" module in the CVS. It already conatins a mostly-finished Bison-based wiki-to-XML parser.

The development is currently halted. Any help would be appreciated :-)

Magnus

Magnus Manske wrote:

3. We change our wiki syntax, however slightly. Besides everyone

using MediaWiki having to learn a new (altered) syntax, we'll have to change *every* page in our databases, including *all* old

What experience do we have from leaving CamelCase markup in 2001? Was there a transition periond when the parser warn against CamelCase? Were all old revisions changed? (Or just mercifully deleted?)

If we are into refactoring the wiki syntax, one thing that might need some rethinking is right-to-left writing systems (Hebrew, Arabic) and how they blend with [[wiki tags]] and <xml or html markup>. This was hardly an issue in 2001, and after this there have been no fundamental changes in Wikipedia's syntax. I don't read Hebrew or Arabic, but trying to read the wiki code on Wikipedia in these languages is more confusing than just the foreign languages.

On he.wikipedia, it seems that [[image: picture.jpg | some text]] is [[txet emos | picture.jpg :egami]], where everything is neatly right-to-left except the filename. But the occasional HTML/XML markup is <tag attribute="value"> in that (left-to-right) order.

Perhaps HTML/XML style markup should be banned from the wiki text before we standardize? We could introduce [[:br]] for <br> etc.