Wikimedia Bugzilla is closed!

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.