Talk:Extension Syntax

I am moving some proposals here which, as defined, do not meet the requirements of being applicable to the different extensions (which is the whole point).--Eloquence 23:33, 5 Apr 2004 (UTC)

I think the XML-Syntax like <math></math> ist no good solution. You have to write a long tag often for a smal formula. I would prefer something like

1. [$ formula $] and
2. [$$ formular $$].

The first expression stands for normal formulars appearing inside text the other one for formulars that should appear centered in an extra-line (but are notated in that text since there belonging to it). The $-sign is the normal symbol in TeX for formulars inside text the "$$-sign" for formulars that should appear in an extra-line. Since wie use TeX to notate formulars this would be a consitent solution. Of course we can use other braces than "[" and "]".

How to differentiate the type of data (tex, score, hieroglyph, etc.)? A☮ineko 17:15, 28 Mar 2004 (UTC)

Thats just the proposal for math-markup (TeX). I did'nt say anything about score, hieroglyphs, etc.

Pros : Cons :

• And if we need ]] in markup ? Regular expression to match \[\[.*\]\] is not a "parser". Taw 18:50, 28 Mar 2004 (UTC)

Sorry, I did not really understand the problem, could you explain it more detailed...?

Oh, and there is another point. I would like to see a small change for the headings-markup. Instead of "=== heading ===" we should use just "=== heading" since this allways apears in an extra-line and do not need parethis (? right word ?). Its from the formating-position the same like "#" for enumeration or "*" for itemizing (its describing a complete block not text inside a block).

Allow links from thumbnail captions, so that this:

[[Image:foo|thumb|A foo in [[bar]] ]]

does the right thing. Lupin 19:34, 3 Apr 2004 (UTC)

I removed some of my proposals I judged non-relevant.

[math]...[/math]

[hiero]...[/hiero]

[music]...[/music]

no / end marker

<math>...<math>

<music>...<music>

<hiero>...<hiero>

To be able to use }} inside the code.

Template:Math:foo:end or Template:Math foo end

Template:Hiero:foo:end or Template:Hiero foo end

Template:Music:foo:end or Template:Music foo end

See examples...

directly as data (like [[image:...]])

[[math:...]]

[[hiero:...]]

[[music:...]]

from data page (like {{msg:...}})

Template:Math:...

Template:Hiero:...

Template:Music:...

See examples...

directly as data

Template:Math:...

Template:Hiero:...

Template:Music:...

from data page (like #redirect)

{{{1}}}

Template:Hiero

Error using {{music}}: unable to parse music symbol ""

How does this one need any special syntax ? You just use [[Image:foo.svg]] and it should be converted to PNG unless the user chose otherwise in preferences. Taw 18:47, 28 Mar 2004 (UTC)

SVG should be editable to fix labels in diagrams, etc. How do we best accomplish that in your scheme?—Eloquence

By being able to edit the text at Image:foo.svg R3m0t 08:14, 29 Mar 2004 (UTC)

That text is the image description page. It should not be abused for source code.—Eloquence

SVG is not meant for editing by hand — just download it, open in some SVG editor, fix and reupload. Taw 01:56, 30 Mar 2004 (UTC)

SVGs in Wikipedia will frequently consist of both text and images. The images are certainly best edited with a graphics editing program only, but the texts can in many cases be edited as is, and we should provide an easy way to do so. SVGs are also typically rather small, and being able to quickly copy & paste them is an advantage, e.g. for translating SVGs between the Wikipedias.—Eloquence 02:35, 31 Mar 2004 (UTC)

There is text there describing the image. Also there are links to allow upload and downloads. Why not a link for editing? What problems would it cause? Leaving raw SVG in the page is nasty: very intimidating. MrJones 12:29, 30 Mar 2004 (UTC)

I think it's important to keep the markup short (as in 'just a few characters to type'), or at least have a short alternative. If the markup is long, like in XML-like people will have a tendency to skip the markup, as it becomes 'too much work'. This is especially true for 'inline' markup, when the markup itself can easily more characters than they thing you markup.

Markup usage time = time to find out which markup to use (t^r) + time to actually use the markup (t^u). XML-type names are highly mnemonic, thus, t^r is very low, but take longer to type. It's the other way around with symbolic names like "[$", where it is difficult to remember which symbol represents which function. More importantly, it is very hard to learn this from reading the wikisource -- it just looks like line noise to the average reader.—Eloquence 16:15, 31 Mar 2004 (UTC)

I agree with this. Short words are much faster to learn, remember, and type than shorter, but confusing, code. Tables are an exception, since there are so many tags to type, and things like game boards are similar. - Omegatron 17:20, 2 Apr 2004 (UTC)

This is two points really:

1. If this decision is going to be final, and have such a wide-ranging effect, I (IMSoP) suggest that this page be publicised as widely as possible, so that users can give their opinions on which they would feel best using.
2. Someone should try and incorporate as many as possible of the points already made on this topic at http://wikisophia.org/wiki/Rend if they aren't already covered.

If we decide a syntax and start using it, I think it will very difficult to change it after (we can use bot to change text, but habit are not so easy to change). I think you can consider this discussion as mediawiki-wide final discussion. Please help to publicize this page before the vote begins. A☮ineko 06:35, 1 Apr 2004 (UTC)

I have made a proposal for creating chess diagrams using tables at w:User:Arvindn/Chess, and several people have said they like it. I hope it will be implemented in MediaWiki. So a tag will be needed in addition to the one for WikiTex. I'm proposing "chessboard", i.e, if we decide on <chess>...</chess> for WikiTex, then this would be <chessboard>...</chessboard>, and if it is [[Chess:...]] then it would be [[Chessboard:...]] etc. -- Arvindn 03:43, 5 Apr 2004 (UTC)

The page is too big for the voting. Couldn't we have a simple sample and respective vote section on each proposal somewhere? Dori | Talk 00:25, 6 Apr 2004 (UTC)

Some of the ideas left out seem to be perfectly adequate to me - or just as much so as the ones that are listed. I agree that the page is rather long, though, so how about we have a Extension Syntax/Voting, and amend the instructions to say:

Please read the arguments for and against below, add look at the concrete [[/Example]]s of each, before [[/Voting]] for or against on any you feel strongly about

Then the suggestions page can be put more or less back to its former state, including some of the pre-emptively abandoned suggestions here. - IMSoP 18:01, 6 Apr 2004 (UTC)

In fact, I've gone ahead and done this, because I tried to vote and found it a nightmare. I may reinstate some of the abandoned options as well, to give them a fair chance. - IMSoP 18:39, 6 Apr 2004 (UTC)

Please don't.--Eloquence 18:53, 6 Apr 2004 (UTC)

Care to give a good reason why not, other than that you don't like them? (Or did I miss a discussion on which ones to shortlist somewhere?) - IMSoP 19:03, 6 Apr 2004 (UTC)

Most of the options were not removed by me, but by Aoineko. He made many very similar proposals. I did not want to prejudge which of these to remove, but since he decided himself to clean up a little, this should not be undone. As for the ones I removed, these simply did not qualify on a technical level (e.g. incomplete). Furthermore, adding and removing options in mid-vote is confusing, and we might end up with some people contesting the vote because their beloved option did not get enough overall exposure, or their hated one did get too much etc.--Eloquence 19:34, 6 Apr 2004 (UTC)

OK... to clarify, though, I was merely going to reinstate the "<math>...<end>" and "{{math:foo:end}} or {{math foo end}}" versions, which seem sufficiently different from anything we have that they might be of interest to someone. I'm in a quandary now: I added one before I saw your original comment, and don't know whether to remove it again, or go ahead and add the other as well. What do you think? - IMSoP 19:45, 6 Apr 2004 (UTC)

Well, since there are already a couple of votes now, I'd suggest leaving it as it is.--Eloquence 19:58, 6 Apr 2004 (UTC)

But not worth the potential confusion of adding "{{math:foo:end}}" at this stage, you think? Just seems kind of arbitrary to have left it out, but I guess the damage is done already now. - IMSoP 20:01, 6 Apr 2004 (UTC)

---

Can I remove votes' date (like 00:25, 6 Apr 2004 (UTC)) to clean the page? A☮ineko 10:17, 6 Apr 2004 (UTC)

Yeah, I'd have thought so. If we go with my plan above, we'll have to move all the votes over anyway, however... - IMSoP 18:01, 6 Apr 2004 (UTC)

Okay, everybody hates the syntax I proposed; perhaps I knew too little about the things other people wanted to do. (I think I missed the beginnings of that discussion.) I still think some kind of replacement syntax is preferable to adding on a new script to the program everytime we want to handle a new extension. I suggested it because not only would it work for things like go, chess, heiroglyphics and simple music, but it allows users to create new markup without having to write a new script each time. This is especially of use for games, admittedly my main motivation for suggesting it. I suppose, under whatever scheme is chosen, we could have a script that could read:

 <replace>
 [[Wikipedia:Mancala replacement images]]
 (4)(0)(3)(2)(1)(5)
 (3)(1)(7)(0)(1)(1)
 </replace> 

where Wikipedia:Mancala_replacement_images is a page setup something like:

 *(0)
 **[[Image:Mancala_empty_pit.png]]
 *(1)
 **[[Image:Mancala_pit_with_1_seed.png]]
 *(2)
 **[[Image:Mancala_pit_with_2_seeds.png]]

etc., so that item * gets replaced with item ** in the output, producing a mancala position? Kevin Saff 18:05, 7 Apr 2004 (UTC)

I think you've pretty much answered your own query in its entirety: the various complex systems like music, maths, hieroglyphics, etc. have already been developed, and so replacing them with a mere replacement syntax would be a step backwards. However, such a syntax could indeed be useful, for circumstances such as you mention - as long as we don't get too many people using it and confusing each other with new and exotic syntaxes. And the overall syntax you suggest there looks very good to me, and wouldn't be that difficult to implement. - IMSoP 21:19, 7 Apr 2004 (UTC)