Last modified: 2014-11-17 10:36:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18337, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16337 - Proposing a new MediaWiki extension : Global Context Variables
Proposing a new MediaWiki extension : Global Context Variables
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
unspecified
All All
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-13 23:33 UTC by Philippe Verdy
Modified: 2014-11-17 10:36 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Philippe Verdy 2008-11-13 23:33:20 UTC
This discussion has just started yesterday on French Wiktionary, but is more general, it was transfered to Wikimedia Forum, but may interest you as well. I have initially copied the initial discussion on the Wikimedia Forum for my initial proposal and some comments (in French) for a specification (before writing code). Translation of the proposal into English is available, and further comments and discussions are welcome.
Most of this large discussion is now included in another page, separate from the Wikimedia Forum : '''[[Meta:GlobalContextVariables Extension]]'''. [[User:Verdy p|verdy_p]] 21:08, 13 November 2008 (UTC)

All arguments are exposed there on Meta, with the description of the immediate problem to solve, but also with many interesting uses of this very versatile extension, to manage the content on many (most?) Wikimedia projects (or on other MediaWiki projects hosted elsewhere).

At first sight, it may look quite technical and complicate for users (yes this would be something new to them, but not much different from the existing template parameters. However the proposal describes very situations where the existing templates are needlessly complicated, and very difficult to maintain by non-experts. The proposal would allows the development of much clearer templates, simpler to edit, and the (progressive) disparition of the "many embedded braces" style, in favor of successive braces, and simulating what you can do MUCH more simply in a traditional programming language.

Currently the most widely used templates (because they are the most useful) tend to grow in size, each time a new parameter is added to them. In addition, new complications are added in templates each time a new parameter is introduced to handle special case. These additional parameters tend to create templates that are finally too difficult to use by non-specialists, and forces them to recreate another similar template. So various variants of templates tend to be multiplied, and generate incoherent content that becomes a nightmare to manage and categorize.

Such extension would allow writing less templates, that are more general, but also simpler to edit, with MUCH less complex embedding of braces (because the linear programming would simplify all this).

The extension will also allow removing many superfluous parameters that need to be repeated throughout articles using the same or similar templates, with the need to provide, at every place, the correct values: this is error-prone and erquires constant management in lots of articles, to make sure that the appropriate parameters are passed coherently according to the context of use or the subject of the page section where these parameters should all be equal.

The extension also allows easier import and adaptation of templates across wiki projects, and would permit the use of the data/view separation model: variables are first set to the computed values to be rendered, then the templates would simply use the values stored in those variables to be rendered in the final article.

Finally, the extension would simplify a lot the code of many complex computing templates such as date computing templates. It will also allow the possibility to manage more than one default sort key for multilingual articles that need to be categorized (and sorted) in several categories related to distinct languages : this is the first need where we need a clean and simple solution in Wiktionary which is a perfect example (in almost all editions) of a multilingual project whose almost all pages contain elements in lots of languages (including the links to translations.

The referenced discussion on meta discusses the problem to solve, the proposed solution, some applications, some technical aspects that need to be monitored, some aspects related to the benefit for saving the server ressources during template expansion.

The initial project is just to propose a way to set and retreive the value of named context variables within a simple block of global variables, but extensions are possible and described to handle:
* lists of values, or stacks (with actions like push and pop instead of just get and set)
* use of context local context variables, whose scope will not exceed the template defining and referencing them, through a simple naming convention enforced by the extension itself
* it preserves a space for extension that would allow various MediaWiki extensions (or the MW core engine itself) to collaborate to the generation of contents, by allowing MW extensions to define and use their own namespace: notably, many existing or future internal MW server variables could be exposed through such variable namespaces, that could be protected within these namespaces, instead of defining new "__MAGIC_WORDS__" or {{MAGICTEMPLATES}} whose naming convention can become very tricky and incoherent.

The proposal initially describes the extension as a ParserFunction using the common prefix "{{#v: }}" (but it could be an anonymous prefix as well like "{{#: }}" or more explicit like "{{#var: }}".

The general syntax proposed is "{{#v:action:variable|parameters}}", where the "action" would be at least "get" or "set" (the default action, if not specified would be "get" so that "{{#v::x}}" would be a shortcut to "{{#v:get:x}}" to get the content of the content variable named "x" (this syntax could be even reduced to "{{#::x}}" is this ParserFunction extension is assigned the anonymous prefix name, or "{{#var::x}}" if the ParserFunction is given the prefix name "var").

The two colons proposed are still there only to avoid the case where a variable name could contain a ":". However, if a naming restriction is enforced (so that no varaible can use a colon in its name) then the syntax to get the content of "x" would be simply: "{{#v:x}}" if the distinctive "v" prefix is assigned to this parserfunction, or "{{#var:x}}" if this prefix is "var", or even just "{{#:x}} if the distinctive ParserFunction prefix is empty (anonymous).

Naming conventions for those variables should be enforced (less liberal than what template parameters tolerate (everything except blanks at the begining or end, no repeted blanks, and no "=" or "|" signs) to preserve future extensions (notably the dot "." could be reserved for future variable namespaces, a leading "_" or "$" could be used to designate local-only variables that do not affect the global context block, for use exclusively within the template using them for storing intermediate values.

I am expecting your reactions and comments on the indicated page on Meta where the proposal may be more readable. This is a draft proposal, no code has been written and should be written before we know what we can do with this extension in some foreseeable medium or long term.

I am also convinced that this extension is quite easy to implement in PHP, using its builtin associative arrays (a single PHP variable would contain an array indexed by the names of context variables that are set in the current "context", in a way exactly similar to the local block of template parameters).

The existing template parameters themselves could also be accessible though this syntax as well, using a namespace/object prefix like "param.": {{{x}}} would be equivalent to {{#v:get:param.x}}, or abbreviated: {{#v::param.x}}. Template parameters, used this way, would become modifiable within the template itself ! {{#v:set:param.x|new value}} would change the value of {{{x}}} for the rest of the template evaluation after it (useful for setting defaults in a way that is much more extensible than the ugly syntax {{{x|default value}}} that must be repeated everywhere in the template where the same default value of {{{x}}} is needed.

The possibilities (combined with the existing {{#if: }}, {{#switch: }}, and {{#expr: }} parserfunctions become tremendous ! And new things could be done in MediaWiki that are currently impossible to imagine due to the existing complexity of the syntax and the limitations that the absence of context are creating.
Comment 1 SV Resolution 2008-11-14 00:14:51 UTC
(In reply to comment #0)
Philippe, you direct us to a discussion at 
> the Wikimedia Forum : '''[[Meta:GlobalContextVariables Extension]]'''.
But when I follow this link I wind up at http://meta.wikimedia.org/wiki/GlobalContextVariables_Extension
Which contains only the message: "This page doesn't currently exist; ..."
I think this might be a very interesting discussion.  Where can I really find it?

The nested curly bracket syntax hurts my eyes, but your proposed extension seems consistant with the existing parserfunction directives.

I think it will be useful to see a partial implementation on a test wiki.  Perhaps something that only does what I proposed in bug 3264?

Good idea

Comment 2 Philippe Verdy 2008-11-14 00:17:24 UTC
correction: the link to Meta does not work as expected from here.
It should be [[Meta:Meta:GlobalContextVariables Extension]] here (but just
[[Meta:GlobalContextVariables Extension]] on Meta !).
or http://meta.wikimedia.org/wiki/Meta:GlobalContextVariables_Extension
Comment 3 Andrew Garrett 2008-11-14 00:22:12 UTC
The problem description is very long, and difficult to follow. You seem to have merged a description of the problem with the basic premise of the extension, and detailed technical implementation proposals.

The report would be better structured with clear headings - what the problem is, how you propose to fix it, and then any technical recommendations you might have as to implementation details.

Can you explain how this is different from the 'Variables' extension?

In brief, these sorts of requests have tended to be denied in the past because we don't want Wikitext to become a programming language. If you want something complicated done, then maybe you should be asking for it to be done in a Parser Function, rather than writing a template.

Of course, we have considered activating a full-blown scripting language, but I don't think Brion likes the idea of that :)
Comment 4 Philippe Verdy 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.

Comment 5 Philippe Verdy 2008-11-14 00:52:20 UTC
You say "In brief, these sorts of requests have tended to be denied in the past
because
we don't want Wikitext to become a programming language. If you want something
complicated done, then maybe you should be asking for it to be done in a Parser
Function, rather than writing a template."

That is exactly what I am proposing: a ParserFunction named here "{{#v: }}" (or
more completely "GlobalContextVariables" for the extension name I gave it
initially, or just "ContextVariables" if it is more general and can also 
handle local variables instead of just globals).

Note that My first desire is for "globals", not just "locals": the variables
must be able to transport a value implicitly across multiple templates
invokations (including through recursion) and even after they return their
result, otherwise there is no usable context in articles, an we still need to
pass parameters to every template invokation.
Comment 6 Chad H. 2010-01-27 05:23:44 UTC
Functionality seems to be provided in http://www.mediawiki.org/wiki/Extension:VariablesExtension (and probably a few other ones by now), so I'm marking this FIXED.

Getting it enabled on Wikimedia sites requires consensus, and approval/review by a senior developer.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links