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)

Ivo's Proposal
I think the XML-Syntax like &lt;math&gt;&lt;/math&gt; 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 &#9774; 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).

Lupin's proposal
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)

= Discussion =

Should SVG be put in-line or linked to?
How does this one need any special syntax ? You just use 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?&mdash;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.&mdash;Eloquence

SVG is not meant for editing by hand &mdash; 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.&mdash;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)

Keep it short
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 (tr) + time to actually use the markup (tu). XML-type names are highly mnemonic, thus, tr 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.&mdash;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)

Wider Discussion
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 &#9774; ineko 06:35, 1 Apr 2004 (UTC)

Chess
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 ... for WikiTex, then this would be ..., and if it is Chess:... then it would be Chessboard:... etc. -- Arvindn 03:43, 5 Apr 2004 (UTC)