https://bugzilla.wikimedia.org/show_bug.cgi?id=16337
--- Comment #4 from Philippe Verdy <[EMAIL PROTECTED]> 2008-11-14 00:45:49 UTC
---
Yes your bug 3264 is related, however my proposal is more consistant with the
existing Wiki style for templates parameters, and more versatile with more
possible interesting extensions (and no ugly XML-like syntax with two
surrounding tags.
My proposal discussed and detailed on Meta can fully manage what you want.
It was made initially on French Wiktionary, then I realized immediately that it
could have a very general use to solve many existing problems with MediaWiki's
core syntax and its severe limitations (the infamous "nested-braces" style that
hurts every one trying to work on templates, and the total absence of context
that forces us to pass and manage too many template parameters, and to
copy-paste the same complex code fragments throughout the defined template,
just because Mediawiki has "no memory" at all.
It is also linked to other discussions that occured last year with people that
wanted the support of variables in #expr. With my extension, it would not be
really needed, because you could store the result of an expression in acontext
variable as well (which does not have to be restricted to contain only text, it
could store numeric values computed by #expr, without converting them to text,
so it would preserve the precision.
My extension could also allow to specify how the value in a context variable
must be displayed, using the proposed general syntax. The default "get" action
is intended to retreive text using the default number formatters, but with a
syntax like {{#v::x|lang=fr}}, using the default action "get" (which is
implicit between the two colons), you could format the number in variable x
using the conventions for French. If you want to retreive the exact value for
use in #expr, this would be possible using e.g. {{#v::x|type=d}} for getting
the "double" (d) value.
Remember the proposed general syntax:
{{#v:action:variable name|optional parameters...}}
Here the part "action:variable" is the first parameter to the ParserFunction,
that splits it on ":" to extract the action and the variable name. Other
optional parameters can be passed by position or by name, just like with
template invokations. In most cases you will only need zero or one optional
parameter: none for "get", one for "set":
* {{#v:get:x}} or just {{#v::x}} to get the value stored in context variable
"x"
* {{#v:set:x|expression}}, or {{#v:set:x|1=expression}} if the expression
contains equal signs, to store a computed value in the context variable "x".
* {{#v:get:x|new value}} or just {{#v::x|new value}} to set the variable x and
immediately get the value at the same place.
Of course the extension has the possibility to become a full programming
language. However the type of use I see will be to simplify a lot of our too
complex templates. and also simplify the use of our templates in articles (by
avoiding to pass again and again the same value.
If you want headings, look at the article linked on
[[Meta:Meta:GlobalContextVariables_Extension]].
My intent is to solve existing real problems (and the first one for which I
wanted it was on Wiktionary, where the discussion started, when one complained
that the sort keys were inconsistant with esperanto, and there was no easy way
to specify multiple sort keys, one for each language that needs a
specialization).
And yes, the solution to the problem involves new powerful features that can
also be abused by real programmers. However every one is horrified by the
complexity of templates, that are already now an affair of specialists, even
for handling the most basic article structure and formatting.
That's why I wanted a syntax that ressembles the most to the existing syntax
for templates, but without its severe limitations: its total absence of memory
of what has already been written and done.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
