"Steve Bennett" <stevagewp(a)gmail.com> wrote in
message news:b8ceeef70711191926j3722bcb9obfe6c5b1487253f5@mail.gmail.com...
On 11/20/07, Mark Clements
<gmane(a)kennel17.co.uk>
wrote:
That's my point. Things like ISBN, RFC, etc.
are magic words. Things
like __NOTOC__ and {{PAGENAME}} are no more magic than
[[Link]], and so shouldn't be described as such.
IMHO, by your logic, __NOTOC__ would not be a "magic" word, but
{{PAGENAME}} would be. Why? Because {{FOO}} is a substitution of a
template called foo. The fact that PAGENAME is a special word (rather
than just the name of a template) is, indeed, "magic".
No {{PAGENAME}} would not be. This would be referred to as a built-in
variable (though see below).
Really, this isn't really about logic in that sense, it's about changing the
way refer to things. Part of this is to make a logical distinction between
the 3 different entities that have a different syntax and a different
purpose (parser directives, built-in variables and automatic links).
We should not be using the word 'magic' for any of these constructs. At
most, the word magic could be used to refer to things that modify straight
text without any extra user syntax (e.g. ISBN, RFC, in-line html links,
etc.) but as far as I know this kind of construct is only used to create
links, so the term 'automatic links' might be better, and again removes a
bit of the mystery.
[skipping ahead a bit...]
* Built-in
variables are enclosed in double curly braces.
Just like templates
Yes. It occurred to me, shortly after writing that post, that they should
not be referred to as "built-in variables", but rather as "built-in
templates". That is the term I shall use from now on.
* Unrecognised
variable names are ignored and are treated as template
inclusions.
Can "built-in variables" take arguments, and if so, how are they treated?
This is resolved if we refer to them as "built-in templates" instead.
[Skipping back to an important point]
* A parser
directive tells the parser to do something (or not to do
something) that affects
the rendering of the article.
That's pretty broad. ''' tells the parser to do something that affects
the rendering of the article. We could narrow it down to "affects the
rendering of the article as a whole", though __TOC__ is pretty
dubious. You could also anticipate behaviour like {{DEFAULTSORT:...}}
being called a "parser directive", and that doesn't affect
rendering...
Hmmm.... well here you've found an exception (and there may be others).
DEFAULTSORT is a parser directive, but it uses the template-style syntax.
This is partly a symptom of the problem I am describing (lack of a formal
definition of these items) but is also probably down to the fact that the __
syntax doesn't support arguments as easily (though I don't see why not).
We need to think about how to resolve this e.g. can we re-define
DEFAULTSORT:
__DEFAULTSORT|Sort key__ seems plausible.
__DEFAULTSORT|{{PAGENAME}}__ seems a little, well, odd... but maybe that's
just because it's new.
Or do we change the syntax to remove all double-underscore directives, and
change them all to use template syntax? In this case parser-directives
could be distinguished by being prefixed with an underscore (e.g.
{{_NOTOC}}). Or we could make them into built-in parser functions
{{#NOTOC}}.
These last ideas are just off the top of my head mind, and need further
consideration. Any syntax changes would of course need to retain existing
functionality (as 'deprecated' syntax) to preserve backwards compatability.
Last question: are you proposing these recommendations
take place
immediately, in the new parser, or some time after that? Does this
formalisation hold true for the current en Wikipedia install? What
about other languages? What are the exceptions to these rules?
Well, if there were no exceptions to the definitions then no changes would
be necessary, as it is just a matter of nomenclature.
The exceptions need a bit more thought - it would be good to identify them
all so we can see what we're dealing with here.
- Mark Clements (HappyDog)