Last modified: 2014-04-01 18:04:42 UTC
I would like the extension:variables installed. It is available at https://www.mediawiki.org/wiki/Extension:Variables It is rated as stable. It allows creating local variables valid only in the current page. The current use case is to define a long string to be used in over 100 templates as part of links inside a larger template page. This extension will help alleviate constant ongoing problems in a frequently accessed and edited page. (Over 400 edits in the last month.) 1) By using a local variable, it removes the problem of typos, very common in the page where it will be used. As well, it will minimize the problem of broken links, as many editors avoid typing the long string necessary to create valid links. 2) It keeps this string local to the only page where it will be used, thus not polluting the template namespace, and avoiding potential name conflicts with other templates. 3) The variable can be defined at the beginning, with a brief description to ensure that it's use is understood, so it becomes self-documenting where it is used. 4) A shorter and more useful name can be chosen than for a template, as a template name would have to avoid ambiguity with other template pages. 5) In the likely case that this string needs to be changed in the future, it can be done more easily, as it will be on the page where it is used. 6) Although this is for use as part of a link, it could equally be used for other cases, as presented in examples on the extension page.
Hi André, thanks for taking the time to report this! (In reply to andré from comment #0) > I would like the extension:variables installed. On which site? For any configuration change, a local consensus is required. Could you discuss the matter on the Village pump page of your wiki to confirm that this change is wanted by the community, and paste the link to the discussion here? Also, please see https://www.mediawiki.org/wiki/Review_queue for a checklist of steps how to proceed before marking this as blocking bug 31235.
This was rejected way back in the day (bug 7865). I assume the rejection still stands. ----- 2) It keeps this string local to the only page where it will be used, thus not polluting the template namespace, and avoiding potential name conflicts with other templates. Fun fact, there are 74106937111882365071085430405560261026092790186009960985252853765064 40296955904 possible template names, (This is an under-estimate, I didn't count most non-english letters). You could easily use Template:PageNameHere/Specific_string_name, or even just make it a subpage of the actual page not in the template namespace, etc. Now namespacing things might be nice just generally, but we're not running out of template names. >It is rated as stable. Just for the record, those ratings are done by the extension author. There are lots of extensions marked unstable which are actually more stable than the stable extensions. So the rating is pretty much meaningless. (Which isn't necessarily to say anything bad about this particular extension, I have no idea how stable it may or may not be) *** This bug has been marked as a duplicate of bug 7865 ***
(In reply to Andre Klapper from comment #1) > Hi André, thanks for taking the time to report this! > > (In reply to andré from comment #0) > > I would like the extension:variables installed. > > On which site? For any configuration change, a local consensus is required. > Could you discuss the matter on the Village pump page of your wiki to > confirm that this change is wanted by the community, and paste the link to > the discussion here? > > Also, please see https://www.mediawiki.org/wiki/Review_queue for a checklist > of steps how to proceed before marking this as blocking bug 31235. Thanks for the feedback. The page in question is a template on the English WP. I've already had contact with someone on the Village pump page, who wasn't aware of this extension. I'll get back when I have the confirmation.
(In reply to Bawolff (Brian Wolff) from comment #2) > This was rejected way back in the day (bug 7865). I assume the rejection > still stands. It is a very bad assumption that a 7 year old rejection is still valid. In case you hadn't noticed, both Mediawiki and extension:variables have changed since then. > ----- > > 2) It keeps this string local to the only page where it will be used, thus > not polluting the template namespace, and avoiding potential name conflicts > with other templates. > > Fun fact, there are > 74106937111882365071085430405560261026092790186009960985252853765064 > 40296955904 possible template names, (This is an under-estimate, I didn't > count most non-english letters). You could easily use > Template:PageNameHere/Specific_string_name, or even just make it a subpage > of the actual page not in the template namespace, etc. Now namespacing > things might be nice just generally, but we're not running out of template > names. Assuming a 2-letter name, that gives only 676 possibilities. But that is not the point. It is not unreasonable to assume that many short names will conflict. Disambiguation pages don't exist for nothing. One advantage of variables local to a particular page is that such variables can be short, thus easier to type, without any ambiguity. As noted above. > > >It is rated as stable. > > Just for the record, those ratings are done by the extension author. There > are lots of extensions marked unstable which are actually more stable than > the stable extensions. So the rating is pretty much meaningless. (Which > isn't necessarily to say anything bad about this particular extension, I > have no idea how stable it may or may not be) > OK. But note that this extension existed in 2006, and was last modified in 2011. So it has been around for a while. And the last 2 (recent) versions are installed on 170 sites. > *** This bug has been marked as a duplicate of bug 7865 *** Not appropriate, for a very old bug rejected for circumstances which likely have changed.
(In reply to andré from comment #3) I don't know what this refers to, but so far it looked like the bug report was about deploying an extension instead. > Not appropriate, for a very old bug rejected for circumstances which > likely have changed. Please provide proof for the "likely".
(In reply to andré from comment #4) > > *** This bug has been marked as a duplicate of bug 7865 *** > > Not appropriate, for a very old bug rejected for circumstances which likely > have changed. Circumstances have in fact changed. However, they've changed such that closing this as anything other than WONTFIX is even more unlikely: VisualEditor and Parsoid require the ability to reparse fragments of the page and then merge the new HTML into the previously-rendered HTML, meaning that new wikitext that affects other parts of the page will not be added (and it's even difficult to fix bugs in Cite due to this issue).
(In reply to Andre Klapper from comment #5) > (In reply to andré from comment #3) > I don't know what this refers to, but so far it looked like the bug report > was about deploying an extension instead. Exactly. I was responding to your comment #1 > > Not appropriate, for a very old bug rejected for circumstances which > > likely have changed. > > Please provide proof for the "likely". Evidently there have been considerable changes to WP since 2006. As well, looking at the changelog of extension:Variables, there was a major re-write for version 2.0.0. (It is now at 2.0.1)
(In reply to Brad Jorsch from comment #6) > (In reply to andré from comment #4) > > > *** This bug has been marked as a duplicate of bug 7865 *** > > > > Not appropriate, for a very old bug rejected for circumstances which likely > > have changed. > > Circumstances have in fact changed. > > However, they've changed such that closing this as anything other than > WONTFIX is even more unlikely: VisualEditor and Parsoid require the ability > to reparse fragments of the page and then merge the new HTML into the > previously-rendered HTML, meaning that new wikitext that affects other parts > of the page will not be added (and it's even difficult to fix bugs in Cite > due to this issue). So you are saying that problems with the implementation of these new features interfere with this extension ? I don't understand. I'm assuming that all this extension does is scan the page, taking the variable definitions and replacing all instances using the defined variables, before any other parsing of the page. The result is a page that shows no evidence of the extension. Is there something that prevents it from processing before any other parsing ? Maybe there needs to be a processing priority established ? Maybe you can explain how any problems with the new VisualEditor and Parsoid are not orthogonal to this extension ? I haven't used VisualEditor yet as I am very comfortable with the older editor, so I'm not aware of any problems there. BTW, to facilitate the use of this extension, WP could always make some supplementary requirement such as the use of the extension be signaled by a definition at/near the beginning of the page. Or maybe restrict it to user: space initially, for testing purposes. I'm not trying to distract you from solving VisualEditor problems, but we have a pre-existing editor which works very well, and extension:Variables is an important enhancement.
(In reply to andré from comment #8) > So you are saying that problems with the implementation of these new > features interfere with this extension ? It's not a problem with those features, it's a design requirement. We had to deal with that requirement when creating Scribunto, too. > I'm assuming that all this extension does is scan the page, taking the > variable definitions and replacing all instances using the defined > variables, before any other parsing of the page. The result is a page that > shows no evidence of the extension. I haven't checked, but I'd imagine the model is more that when the parsing process calls the hook for #vardefine it sets some internal state, and when it calls the hook for #var then it returns that internal state. Much like how with Cite a <ref> sets some internal state and <references> uses that to construct a list of references. > Maybe there needs to be a processing priority established ? Let's not add even more passes to the parser. The Parsoid folks already want to do that for Cite (and do do it in Parsoid). > Maybe you can explain how any problems with the new VisualEditor and Parsoid > are not orthogonal to this extension ? Because wikitext needs to be parsed? > I'm not trying to distract you from solving VisualEditor problems, Not my department anyway.
(In reply to Brad Jorsch from comment #9) > (In reply to andré from comment #8) > > So you are saying that problems with the implementation of these new > > features interfere with this extension ? > > It's not a problem with those features, it's a design requirement. > > We had to deal with that requirement when creating Scribunto, too. Evidently. And it works very well, at least on pages I've seen using it. Such modules can be a tremendous improvement over pure templates. > > I'm assuming that all this extension does is scan the page, taking the > > variable definitions and replacing all instances using the defined > > variables, before any other parsing of the page. The result is a page that > > shows no evidence of the extension. > > I haven't checked, but I'd imagine the model is more that when the parsing > process calls the hook for #vardefine it sets some internal state, and when > it calls the hook for #var then it returns that internal state. Much like > how with Cite a <ref> sets some internal state and <references> uses that to > construct a list of references. It would be setting a value for a token, and replacing tokens with that value. Simple text replacement, as it passes through the page. There are some more complicated options, but they could be ignored by WP if difficult to implement. For instance, there could be a bar to using recursion. > > Maybe there needs to be a processing priority established ? > > Let's not add even more passes to the parser. The Parsoid folks already want > to do that for Cite (and do do it in Parsoid). But additional passes can be a very effective way of simplifying the problem. Often with little or no cost in performance. > > Maybe you can explain how any problems with the new VisualEditor and Parsoid > > are not orthogonal to this extension ? > > Because wikitext needs to be parsed? Logically, the simplest solution for extension:Variables is to have a priority parsing pass to itself. Once that is done, the resulting page shows no evidence of the extension. If there is a relatively straight-forward way to signal the use of the extension in the page (such as a definition near the beginning of the page), the performance hit for other pages should be minimal if any. Maybe the parser could do an initial scan of the page to enumerate all the extensions/modules used in the page (if it doesn't already), and then do parsing passes according to an appropriate priority. Many but not all could be done in parallel. Extension:Variables being an obvious exception. It's not rocket science. (To experienced programmers, at least.) If there is a problem with how extension:Variables is implemented, I'd be interested in writing a similar very simple equivalent, that does nothing more than act as a preprocessor, replacing one or more variables with literal text in a single pass. In my mind that is all that most uses of such an extension would be anyway. And it does fill a void, between templates and modules created with Scribuntu/Lua
