[Bug 16337] Proposing a new MediaWiki extension : Global Context Variables

2010-01-26 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=16337

Chad H.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from 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.

-- 
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
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 16337] Proposing a new MediaWiki extension : Global Context Variables

2008-11-13 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=16337





--- Comment #5 from Philippe Verdy <[EMAIL PROTECTED]>  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.


-- 
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
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 16337] Proposing a new MediaWiki extension : Global Context Variables

2008-11-13 Thread bugzilla-daemon
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
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 16337] Proposing a new MediaWiki extension : Global Context Variables

2008-11-13 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=16337


Andrew Garrett <[EMAIL PROTECTED]> changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Comment #3 from Andrew Garrett <[EMAIL PROTECTED]>  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 :)


-- 
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
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 16337] Proposing a new MediaWiki extension : Global Context Variables

2008-11-13 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=16337





--- Comment #2 from Philippe Verdy <[EMAIL PROTECTED]>  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


-- 
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
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 16337] Proposing a new MediaWiki extension : Global Context Variables

2008-11-13 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=16337


SV Resolution <[EMAIL PROTECTED]> changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Comment #1 from SV Resolution <[EMAIL PROTECTED]>  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


-- 
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
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l