On 08/02/12 11:20, Pavel Tkachenko wrote:
(Continuing the crunching. huh? But this message is only 4 pages long.)
Forked into the new thread.
I'm afraid latest maillist messages were considered TLDR by most of the subscribers so I will put this in the beginning: is there any point in continuing our discussion on the subject? Platonides is a constructive company but he seems to be the only one participating.
Is the community truly interested in reworking the markup?
I doubt so.
I have some knowledge and code assets that I will be happy to contribute; I will gladly take part in discussions or help improve the situation in some other way. But if Wikimedia team has different views onto the markup evolution it's fruitless to spend so much time chatting before the closed doors.
My reply follows.
On 08.02.2012 2:27, Platonides wrote:
Nobody proposed to change the template in that way? :)
You mean that nobody has actually studied markup usability?
I just mean that noone standed up and proposed "Hey, this would look better in this different way". Anyone can create new templates, with any name and parameters he wishes. So albeit their good intentions, they may not be the best way to do it. And templates are rarely refactorized.
(...)
So, how do you split {{About Bijection, injection and surjection}} ?
If that is supposed to be a long caption (4 words and a comma) then just use quotes - like in natural handwriting. {{About "Bijection, injection and surjection"}}
The point of using an additional character not used in normal language is precisely for working the metalanguage.
I disagree, it only means that this subject has not yet been researched enough.
Also, there are colons as parameters. How would you write as the parameter the article [[Gypsy: A Musical Fable]] or [[Batman: Year One]] ? By banning ':' in titles?
Have I said something about colons and links? Links are fine with colons or any other symbols.
You mentioned colons for template arguments I'm acting as the devil's advocate asking you how to provide those titles as parameters to a template.
Uh, I have mistyped "comma" instead of "colon". Let me correct this:
- {{About Something}}
- {{About Something, of kind}}
- {{About "Something, something and something", of kind}}
- {{About "Something, something and something", "of kind, kind and kind"}}
As you can see, no character is banned from the title (...)
What about the separator? Eg. [[The character "]]
But if we're touching this pipes in links are not that intuitive either. Pipes are actually not present on many keyboard layouts but even apart from that it's more natural to use an equality sign. Or double, for the purpose of text markup.
It's consistent with the use of pipes in templates (which do use equal in that way to name parameters). Although link syntax was probably earlier.
Right, and pipes should not appear in templates either. It's too special symbol.
Why so? So far the only reason you gave is that it's not on all keyboard layouts.
So is [[Batman Forever]] your syntax for [[Batman Forever|Batman Forever]] or [[Batman|Forever]] ? So much cases are bad, KISS.
I do not see your point. The processing is straightforward:
- Link contains == - it separates address from title.
- Link contains no == but contains a space - the first space separates
address from title. 3. There is neither == nor ' ' - link is titleless. This means that:
- local links get titles from page name, not page address (this is
important and differs from current MediaWiki implementation in a better way)
- remote links can also get their title from <title> after fetching
first 4 KiB of that page or something
No way. That can be good for preloading a title on link insertion and storing it indefinitely, but not for doing it every time.
Use cases:
- "[[http://google/search?q=%61%62%63 Google it]]" - for external links
== delimiter won't be used at all
- "See this [[page]]" - current wikitext is the same
- "See [[page that page]]" vs. current [[page|that page]]. Looks more
clean and easier to type (space is present on all keyboards and is quite large in size). This covers not less than half local links.
Only if pages with no spaces are more common than pages with spaces in the name. Taking enwiki articles as a sample: * 7746101 articles with space. * 1416235 articles without space.
So more often than not the wouldn't be useful. However, you could take advantage of the space-is-underscore, and use [[Some_page this page]] (but still not 'clean')
- "See [[Some page==this page]]" vs. current [[Some page|this page]].
This case has less drastic differences than previous 3 but a pipe is still both special to English layouts and less noticeable to human eye than double equality sign.
Does "KISS" mean that every use case should be created with uniform but because of this equally inconvenient syntax? I agree that more complex cases should have correspondingly more complex syntax but this scaling must be adequate. By placing pipe everywhere not only cross-language usability is reduced but the fact that it's redundant in some cases (#1 and #3 items above) is ignored.
- Finally, in very rare cases when both space and equality symbol
is necessary a special markup-wise (!) escape symbol can be used.
As an example: [[2 + 2 = 5]]
Your example contains no double equality symbol and is treated as space-separated title: [[2| + 2 = 5]] in current wikitext.
Would you remove === headings?
No, headings are consistent because the first heading starts with double equality sign.
Nitpicking, first heading has just one equal sign [at each side] :)
I'm not sure this is a good analogy. Copy-pasting chunks of code look like copying phrases from other articles to make your own. That should be original. OTOH, reusing the existing LaTeX template is much more appropiate than writing your own from scratch trying to copy the style of the provided one.
For such things templates must be created that will reduce the number of entities identical to all of their use cases to minimum. In MediaWiki this is done using {{templates and=parameters}} and this is good. If you were talking about copy-pasting these templates, their parameters and empty values - this is fine. But if it was about copy-pasting the same code with all rendering tricks ( , {{iejrhgy}} and other cryptic things) - this is bad.
Yes, i mean about copy-pasting templates, and then the users changing the parameters to a more suitable value. You can't expect people to just start writing and think of "I'll write {{Infobox Planet}}" :). Copying the article headings can also be useful.
Even if I write a program from scratch, I should make it consistent with other tools. That means an appropiate arguments would be sort -r --ignore-case --sort=month ./myfile instead of sort<- !case (sort as month) \\./myfile\\
Standardizing is fine unless it starts looking unnatural. The following example might be argued but I can't think of another one quickly: tar -czf file.tar.gz .
Not a bad example, as that's one of those utilities with odd parameters "There are three styles for writing operations and options to the command line invoking `tar'. The different styles were developed at different times during the history of `tar'..." (exract of GNU tar info page)
While this uses standard CLI syntax is in true *nix ideology this is what (among other things) separate POSIX from Windows. For instance, I could write: tar file.tar.gz .
...and the program will detect -czf arguments on its own based on -f is simply implied because there are 2 unnamed arguments (without leading -X) -c target file doesn't exist -z target file has extension .gz
That's a source of problems. It's fine having dumb programs that you need to walk-through. When the programs are smart, if they don't go up to the leve, that's an issue. http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/5#address-boo...
In this case "tar file.tar.gz /mydata" sometimes could create a backup called file.tar.gz, and sometimes could put file.tar.gz and /mydata inside a newtar.out file. (I'm assy¡uming it's refusing to implicitely send it to stdout when it's a tty).
It's the same with templates or other markup: while {{About page=Earth kind=planet}} or something similar is fine, {{About Earth, planet}} or some other form is more appropriate in this particular use case.
You are giving many attributions to the machine. Personally, I would spit out an error, just in they were eg. in different units.
Yes, this is one of the ways and I would opt for it if we want to have a strict syntax.
But you are making up your syntax, then requiring the system to adapt for you.
Can you elaborate more on this point?
The goal of wikitext is to make html editing easy.
HTML editing? I thought wikitext was about text editing. Why not edit HTML using HTML?
Because it's considered cumbersome. (Actually, it's presentational editing, but as the presentation is obtained by using HTML as an intermediate language...)
Indeed, HTML is cumbersome, that's why wikitext and all other text markups have been invented. But they don't have to copy HTML syntax - just the opposite.
And you have complicated the originally clean syntax of 1, 2, 3
Clean syntax for whom? For Englishmen? And are hashes actually clean? If so, why don't we use them in our e-mail messages?
No. Clean syntax of 1. Foo 2. Bar 3. Baz
Would html links become italic? (that was a problem of wikicreole, it was defined as 'italic unless in links')
Not at all because we are talking about context-specific grammar. Addresses in links can hold no formatting and thus all but context ending tokens (]], space and ==) are ignored there.
Oh, you're not autolinking urls.
And yes, context-specific grammar is more than regular expressions can handle. Regexps are good but this doesn't mean anything incompatible with sed is beyond "too complex".
As already mentioned, I am using my own markup processor written in PHP on my projects and it implements all markup already described including the [[http://italic]] (context-specific grammar) case. And its parsing loop is under 350 lines of code.
Well, I have to say it seems well though, it "doesn't look bad".
Thank you. I have given it a lot of thinking and practice but I'm sure there still are things to improve. I would be ecstatic if my experience can help the world's largest free knowledge community.
Thanks again for your mail, Platonides.
Signed, P. Tkachenko