Extension talk:TemplateData

Jump to navigation Jump to search

About this board

Odd Issues With Editing TemplateData In Visual Editor

Summary by Thiemo Kreuz (WMDE)
Bjsdaiyu (talkcontribs)

Note that in a relatively fresh install of MW 1.35 / VE, attempts to edit Templates using TemplateData information results in this kind of poorly formed reference to the Template in question, forcing one back to source code editing. After some digging, it turns out that $wgArticlePath *must* be set to something (e.g. "/$1") other than the default, otherwise javascript code in the VE extension (specifically, mw.libs.ve.decodeURIComponentIntoArticleTitle in modules/ve-mw/preinit/ve.utils.parsoid.js) will not properly extract the title (Template:Cite Book in the example) from the default index.php?... URI.

Thiemo Kreuz (WMDE) (talkcontribs)

I tried to replay the issue based on what you wrote, but wasn't able to. My setup appears to be similar, with URLs like http://localhost/index.php?title=Template:Cite Book. Still what VisualEditor displays is the proper template name.

The source code file you mention is probably not the source of the error. I believe that happens earlier. I also wonder why your screenshot shows "Index" with an uppercase "I" and an ":" before? Can you please provide more information about your setup?

Bjsdaiyu (talkcontribs)

Sure, here are (VM, so passwords unsanitized) NGINX and LocalSettings configs for MW1.35 in a state where the issue should be occurring:



Unsure about what's going on with that strange capitalization, my guess is higher-level formatting based on the incorrect assumption that it's a page name and therefore should be capitalized (doesn't really explain the initial ":", though). Since changing $wgArticlePath fixed the issue for me, I suspect those are superficial formatting problems thanks to bad input. My suspicion about decodeURIComponentIntoArticleTitle stems from the fact that it really does nothing of the sort, it simply de-escapes the URI without performing any extraction of the actual ArticleTitle (from the URI) at all, which is precisely what is observed from the front-end. Specifically the following chain of events seem to occur:

1) the href referring to the clicked-on template is passed to normalizeParsoidResourceName



ve.dm.MWTemplateModel = function VeDmMWTemplateModel( transclusion, target ) {

       // Parent constructor

       ve.dm.MWTemplateModel.super.call( this, transclusion );

       // Properties

   this.target = target;

   for (var i in target)


console.log("BJS "+i+" "+target[i]);


       // TODO: Either here or in uses of this constructor we need to validate the title

       this.title = target.href ? mw.libs.ve.normalizeParsoidResourceName( target.href ) : null;   /// BJS ********* href ./index.php%3Ftitle=Template:Book

       this.sequence = null;

       this.params = {};

       this.spec = new ve.dm.MWTemplateSpecModel( this );

   this.originalData = null;


2) normalizeParsoidResourceName is essentially a wrapper to parseParsoidResourceName, which in turn passes the decoded URI to decodeURIComponentIntoArticleTitle



mw.libs.ve.normalizeParsoidResourceName = function ( resourceName ) {

        return mw.libs.ve.parseParsoidResourceName( resourceName ).title;


mw.libs.ve.parseParsoidResourceName = function ( resourceName ) {

        // Resource names are always prefixed with './' to prevent the MediaWiki namespace from being

        // interpreted as a URL protocol, consider e.g. 'href="./File:Foo.png"'.

        // (We accept input without the prefix, so this can also take plain page titles.)

    var matches = resourceName.match( /^(\.\/|)(.*)$/ );

    console.log("BJS utils.parsoid matches "+matches);

    console.log("BJS utils.parsoid matches decoded "+mw.libs.ve.decodeURIComponentIntoArticleTitle( matches[ 2 ] ));

        return {

                // '%' and '?' are valid in page titles, but normally URI-encoded. This also changes underscores

                // to spaces.

                title: mw.libs.ve.decodeURIComponentIntoArticleTitle( matches[ 2 ] ),

                rawTitle: matches[ 2 ]



3) However, and I believe this is where things go horribly awry, decodeURIComponentIntoArticleTitle does nothing of the sort, it simply runs decodeURIComponent against the string, without extracting the article title (which is presumably what is intended per the function name) - so everything that subsequently uses template.title is in fact still using the URI, not the article name.



mw.libs.ve.decodeURIComponentIntoArticleTitle = function ( s, preserveUnderscores ) {

        try {

            s = decodeURIComponent( s );

        } catch ( e ) {

            console.log("BJS error");

            return s;


        if ( preserveUnderscores ) {

                return s;


        return s.replace( /_/g, ' ' );


Reply to "Odd Issues With Editing TemplateData In Visual Editor"

Possible to {{subst: ... }} a template into article using Insert>Template?

3 (talkcontribs)

Apologies if this is not the right place to ask this--

I am using a template with parameters and TemplateData so that a user can Insert > Template into an article via VirtualEditor. I'd like to have the end result on the article page to be a substitution since more content will need to be added in the middle of the resulting substitution.

Is it possible to do this, and retain the use of the Insert>Template wizard? Thanks (talkcontribs)

Nevermind, figured out it's possible by adding subst:TEMPLATENAME in the template search field after choosing Insert>Template. Got it to work on a simple template but not yet on the one I originally needed it for...hmmm...at least I know it's possible.

Help:VisualEditor/User guide#Template parameters

Whatamidoing (WMF) (talkcontribs)

I'm glad that you figured it out, and also that you took the time to post the solution for the next person. Thank you.

Reply to "Possible to {{subst: ... }} a template into article using Insert>Template?"

Not seeing any benefit with Visual Editor though I hope to

WikimeSteve (talkcontribs)

We have this extension deployed. The tags on template pages are consumed and displaying the parameters and such correctly. We also have the button and link on the edit template view and the parameter editor pops up. We have the Extension:VisualEditor installed and it works fine. It integrates with Extension:WikiEditor.

Maybe I am expecting something that I should not. When I go to a page and I chose to add a template I get the same old dialog box. I open the options and see nothing. I am expecting that I will see a list of the parameters feeding into this and helping prompt me for choices. I tried Template:Lorem_ipsum which we imported from Wikipedia.

Additionally when I tried this Template:Lorem_ipsum on my user page at Wikipedia I get an icon that allows me to insert a template in Extension:WikiEditor which I do not have in my Extension:WikiEditor view. That opens a dialog that is clearly showing the parameters which is what I would like to have on our Wiki. I realize that this paragraph may be referring to a different issue.

I see nothing about this in the configuration but at the very bottom I see the link to Extension:VisualEditor. Is there a setting I missed? Can you suggest anything else that might be blocking this use?


Whatamidoing (WMF) (talkcontribs)

The 2010 WikiEditor does not use TemplateData. The effects of TemplateData should be visible to you in the visual editor (e.g., here) but not in the old WikiEditor (here).

WikimeSteve (talkcontribs)

I see the same result on the sandbox page you provided. Maybe I am not doing something right. I go to the Insert menu and select template. I then see the plain dialog result but I see no prompting. Or is it just that there is a link to the pages view of the paraments but no menu items added? Is that all the integration I should expect?

Our Wiki:

MediaWiki 1.31.0
WikiEditor 0.5.1
TemplateData 0.1.2 (0cffe4a) 11:36, 15 October 2018
VisualEditor 0.1.0 (13a585a) 15:14, 30 May 2018

Additional info. Just found out the Template:Lorem Ipsum on Wikipedia is quite different than on Medaiwiki. So I tried Template:Banner. This one does show a prompting fields for Image and Title. This is what I would expect and do not see on our Wiki. For reference the https://en.wikipedia.org/wiki/Template:Lorem_ipsum is the one I have been trying and which we have on our wiki. It has several parameters.

The left shows my Wiki. The right shows the MediaWiki sandbox page you sent. I imported the Template:Banner to my staging so I could better compare.

Jeblad (talkcontribs)

The message at the top clearly says the description is missing, thus something is not correctly configured or you did not import the part of the template with template data.

WikimeSteve (talkcontribs)

I do see the same code in source view but the display of the template has one difference. This image shows my instance above original., I am not sure why I see this Title with 3 curly brackets:

Also I just clicked on the Manage Template in edit mode and I see the Description field does have "Template for full-width images with inset text." in it.

Yes I think this is a configuration issue but what. The instructions look pretty straight forward and we did nothing beyond what is in the installation part. Any ideas what other settings we might check for?

WikimeSteve (talkcontribs)
More images for troubleshooting disconnect between VisualEditor and TemplateData

Been trying to figure out why TemplateData seems 100% within itself. It is only when VisualEditor tries to consume it I see no connection. As Jeblad pointed out above, VisualEditor says there is no description but the TemplateData editor shows that there in one. Is there some configuration I should check in the on VisualEditor? https://www.mediawiki.org/wiki/Extension:VisualEditor#Complete_list_of_configuration_options shows some items that might be required but I see nothing documented.

Here is a screen shot that shows the Collapsible List template in the TemplateData editor view looking fine. When I try to call it from VisualEditor it shows no parameters and says there is no description.

Jeblad (talkcontribs)

Use the console and try to check whether VE hits the correct API endpoint, and that the API responds as it should do.

WikimeSteve (talkcontribs)

First I am not at all sure what you mean. Will see if I can sort that out.

In the meantime a weird update. If I go to a clean spot on the page and try to use the drop down to add the new reference to the template I still get no prompting and it says no description. There is the link to the template though. In playing with it I decided to add a sample conversion from the doc page {{convert|2|and|5|km|mi|sigfig=3|abbr=off}} to a page using source view. I saved the page and the template ran as expected giving me the conversion.

I then clicked on Visual editor. The screen shot shows that the prompting showed up fine. This is in my staging environment. We do not have the Extension:Templatedata in production yet. We do have the templates. I tried the same and get the prompting there when editing a template call that is first saved with at least some parameters.

So both environments fail to allow us to initiate the template call from VE with parameters but both allow the prompting of the parameters with their labels if they exist when the call is made from Source view first. One environment has the templatedata extension and the other does not so prod templates show the raw xml stuff not the nice box.

Whatamidoing (WMF) (talkcontribs)

On the Wikipedias, because of job queue limits, sometimes you have to purge the template page (not the /doc page or article – the "Template:Whatever" page itself) to make the TemplateData visible to the visual editor. I don't really expect this to be a problem on a smaller system, but perhaps it's worth a try, since it's so easy to do?

WikimeSteve (talkcontribs)

Tried this per your suggestion with no help. Thank you for the suggestion. I was hopeful.

It does make me wonder if I should have the box admin get on and make sure all queued jobs are clear and then run maintenance like rebuildall.

WikimeSteve (talkcontribs)

Appears to be solved. We had 5900+ jobs queued and got those cleared out. We then ran Rebuildall which took an hour. I had imported and set up a good number of the templates. After those two tasks, so I cannot say for sure which one but I suspect Rebuildall, I went to my blank page and tried inserting a template. Noticed right away that the description was now showing up in the search window as the results came back. After selecting it I saw all the fields as expected.

Thanks for the responses and help.

Whatamidoing (WMF) (talkcontribs)

Thanks for coming back here to tell everyone what happened. I hope someone else will find this note and be saved a lot of frustration.

TiltedCerebellum (talkcontribs)

My issue with this had nothing to do with the job queue, which was empty, it turned out to be an issue in the database.

Reply to "Not seeing any benefit with Visual Editor though I hope to"

Enter a parameters params with the VE interface?

Summary by TiltedCerebellum

In our case once upon a long time ago the database got borked (not by me) on upgrade and it was repaired, I think this issue stems from that as I've ruled out everything else systematically. Works on a clean site with pages imported, I'll do that.

TiltedCerebellum (talkcontribs)

How are "params" entered using the "Manage Template Data" button? Can they not be added this way? At current it looks like it's possible to add these but only manually, why? Or if it is possible to add it via the "Manage Template Data" button, how?

"sets": [
            "label": "Date",
            "params": ["year", "month", "day"]

Also, can someone help in determining why VE can't see the Template Data for templates?


Template data included in template, noinclude tags necessary?

TiltedCerebellum (talkcontribs)

So I installed the extension, created some template data inside a template, then because I saw no mention of noinclude tags being necessary, tried using the template in a page, and the template data is included in the template. Probably predictable yes but it should be on the extension page. I was concerned that the noinclude would make it not show up in VE... so I combed over the extension page again and did CTRL+F and saw no instances of . Turns out this information is buried in the Help:TemplateData Page. Perhaps it can be also added somewhere on the extension page, or at least that noinclude won’t impact its ability to be seen and picked up by VE.

Could use another boolean type

Summary by (talkcontribs)

Many templates, on English wikipedia at least, have boolean parameters which take any non-empty value as "true". Commonly entered as "option=y", but "option=0" would work just as well.

This is sufficiently common that I think a parameter type for this would be useful. The existing "boolean" type uses 0/1, which doesn't work; the pattern is blank/nonblank.

Tacsipacsi (talkcontribs)

I agree, it would be very useful; currently I documantate such fields as unknown type. I think the most common way to store them is “1”, probably customer applications (such as VisualEditor) should use this. (talkcontribs)

It is more complicated than that, suppose an infobox has a value that determines if someone has grandchildren. This can either be true, false or unknown. Leaving it blank may mean that the editor simply doesn't know if someone has grandchildren, as opposed to setting it deliberately as false.

Still, it might be a good idea to a way to enter a set of truthy or falsey values allowed in a template.

See : https://phabricator.wikimedia.org/T144155

Tacsipacsi (talkcontribs)

The grandchildren example is already documentable with the boolean type. This is about the parameters where all values are evaluated as true. Let’s suppose there’s a template which produces a table that may have a border, but doesn’t have by default. The border parameter is used to make it bordered. The following code evaluates it in the template:

<table {{#if:{{{border|}}}|style="border:1px solid;"}}>

In this case, there can’t be unknown as the editor should know whether they want a border. Any value is considered true so I can’t enter every truthy value. (talkcontribs)

I'd say the benefits of allowing specific values for true outweigh the costs. It is especially important in the context of templatedata, as it is meant to bring a bit of sanity to the templating chaos.

Currently with that template any gibberish can mean true, e.g. "...........", "zbzbzb", etc.

Like noted before the solution might be to define truthy and falsey values, e.g.:

True values: [1, yes, y, true] - default = 1

False values: [null, 0 , false, n, no] - default = null

Null would be equivalent to setting false, e.g:

{{mytable| border = }}

Perhaps these could be set as sitewide defaults to make it less burdensome, and eliminate the need to set it in every template while still maintaining some standards. In fact, in english wikipedia, that's what seems to do. (talkcontribs)
Tacsipacsi (talkcontribs)

I think I haven’t written that each template should store its truthy and falsey values, of course most of the time it’s not needed. (The rest should be rewritten to at least understand the standard values.) I wrote that we should have two boolean types:

  • 3-state is what we have now (1=true, 0=false, null=unknown).
  • 2-state is the new (any value [stored by VE as 1]=true, null=false). Empty string is usually false, but it can be sometimes true. The string “0” means true. There’s a template in Hungarian Wikipedia where the parameter is named in a way that writing “no” is the logical text while it means technically true. Processing this as the 3-state would produce it to be displayed (or even overwritten) wrongly. Of course when using a checkbox, it’s all right to store it as “1”. (talkcontribs)

Personally, it seems that the current state works for most cases. Two state is fine, but it will probably need to be a different phabricator request, as the current spec was specifically designed to have 3 states if it is important for several wikis.

Maybe a templatedata flag (or option) for any truthy, and null falsey.

Jdforrester (WMF) (talkcontribs)

The complexity of coming up with which of the hundreds of definitions of truthy we'd use are exactly why we didn't implement this. I don't think we'd likely get consensus on which definition to use. (talkcontribs)

The thing is that for better or worse MediaWiki got people used to the notion that a template parameter with a "any text" is true, and no text is false because of the {{#if parser function. Although that parser function isn't part of mediawiki, there is likely a core magic word that treats it like that.

It will be hard to convince people to change thousands of templates to change this assumption, but it will be easy to add to the spec and make it to treat it differently e.g.:

 Parameter = border
{{mytable | border = 1 }} -> True
{{mytable | border = }}  -> false
{{mytable}} -> false

Changing any template that doesn't fit those assumptions is way easier than changing most templates to consider "0" as false.

Other alternatives include setting a new magic word, that evaluates to truthy or falsey ,e.g. {{+}} or {{-}}, {{✓}} or {{x}}. These could still substitute the above values. The final alternative is to set an interface page that defines the values of truthy and falsey.

New magic words or parser functions are bad solutions. As they just add to the complexity instead of reducing it. (talkcontribs)

One example of a core functionality that works this way is the default template argument, e.g.:


It will only fallback to red if border has no string. So I guess you'd easily get consensus for truthy that works like that because that's what mediawiki established as a norm, and has used close to a decade (or more).

Whatamidoing (WMF) (talkcontribs)

I'm a little worried about this approach, which seems to indicate surprising and unwanted results:

{{mytable |border = false}} -> True?
{{mytable |border = no}} -> True?

Maybe we should have better logic than that in our templates.

Tacsipacsi (talkcontribs)

It’s about existing templates’ existing transclusions. One won’t go through all transclusions one by one to check if there are any “surprising” values (which may be not as surprising, depending on the parameter name) just to make sure VisualEditor won’t mess up everything. So yes, these values should be accepted as “true”, although no tools are required to store them this way. (talkcontribs)

> I'm a little worried about this approach, which seems to indicate surprising and unwanted results:

Well, previously wikitext editing couldn't help the editor with which values are "default", but VisualEditor and the newer source editor have a dialog that can help. So it is easier to change fewer templates to conform to the null boolean (value / NULL).

Alternatively, in other instances, the template editors can always change it to accept something like this:

<table {{#if:{{yesno|{{{border}}}}}|style="border:1px solid;"}}>

So the template can keep working with minimal changes. The point remains that these changes should preferably be the exception not the rule. (talkcontribs)

Here's a crazy idea:

Instead of changing templateData to conform to editors' strange templating "techniques", a flag / setting can be added to Extension:Parserfunctions to treat 1 / 0 as true / false in addition to the default. If this is customizable then that would eliminate the need for template:yesno as admins could set it wiki wide. So in effect the two template calls below would be essentially the same:

true  = 1 , true, y , yes, default = *string*
false =  0, false, n, no , default = *null*
 mytable template
{{#if:border|red-border| blue-border}}
 {{mytable | border = true}}   === red-border
{{mytable | border = 1}} === blue-border
 {{mytable | border = false}}   ===  blue-border
{{mytable | border = 0 }}  blue-border (talkcontribs)
{{mytable | border = true}}   === red-border
{{mytable | border = 1}} === red-border
Tacsipacsi (talkcontribs)

{{#if:}} shouldn’t be changed. It works this way for over ten years, simply it cannot be seen what it will break in and outside of the Wikimedia world.

Whatamidoing (WMF) (talkcontribs)

I'm thinking that actually should be changed, if the behavior is truly as surprising as this "War = Peace" construction seems to be.

MediaWiki has a process for announcing potentially disruptive changes, so that people can prepare for them. There's a series of disruptive changes being planned now, and no clear reason why using standard conventions for marking a value as false couldn't be added to the list.

Let's see: User:Tim Starling (WMF), is this "false=true" thing in template logic part of Parsing's remit? Or should it be brought to another team's notice?

Tacsipacsi (talkcontribs)

If we change, it can break really many templates, I don’t know about any other such big changes in MediaWiki. On the one hand, we don’t have to create {{yesno}} on many wikis; on the other hand, it needs i18n, which makes it less portable, or can cause problems even within one language. For example, “nem” means “no” in Hungarian, which would have false value. But it also means “gender/sex”, which should be true in an infobox building template:


which is called as

{{Infobox/General|Nem|Férfi<!-- Male -->}}

Lua also interprets the string “false” as true:

a = "false"
if a then
	return 1
	return 0

returns 1.

Whatamidoing (WMF) (talkcontribs)

Compared to Parsing/Replacing Tidy, I think that this is a pretty small change. See, for example, these 1,000+ pages at huwiki that will have formatting errors – and that's just for one of multiple changes in that project.

It's important to remember that no templates require editors to put in |para=false to evaluate an expression as true. No changes will need to be made to the templates. So what we're really looking at is a tiny percentage of template uses that might have unexpected results. Unless your wiki has someone who has been deliberately and systematically adding |para=false because he thinks it's fun to see MediaWiki's templates evaluate "backwards" from common programming conventions, this change is unlikely to affect many pages.

TheDJ (talkcontribs)

Template logic is really complex, and really dependent on these kinds of paths. I think it is much more difficult to predict the effects for this, than compared to tidy changes.

Tacsipacsi (talkcontribs)

What will change around <br>’s? They are auto-closing tags so any form should be equivalent to the XHTML <br />, shouldn’t it?

As I mentioned some kilobytes before, I have written “no” in template parameter, which was processed as true, but not because I think “it’s fun to see MediaWiki’s templates evaluate ‘backwards’ from common programming conventions”, just because given the parameter name and the meaning of the filled parameter, it made sense this way.

I still don’t know why is it worth to change a function after ten years: it doesn’t make extension programming easier as we still need a two-state and a three-state boolean type to handle properly if there’s an undefined state. However, it makes many things backwards incompatible and is way harder to fix than some HTML tags.

Whatamidoing (WMF) (talkcontribs)

Those pages don't have <br>. They all have </br>, which isn't 'legal' according to any standard.

Tacsipacsi (talkcontribs)

I know this search is for </br>. I meant “<br>’s” for all tags with the tag name “br”, i.e. <br>, <br />, and </br>. I know the latter is “illegal”, I wondered what will actually change around it. If the only change will be that from then on it won’t be valid HTML5, but browsers display it as now, than it’s not a problem. If it will be rendered in another way, e.g. hidden or displayed as it is (as text), it should be changed, which is a very easy task for any bot.

Whatamidoing (WMF) (talkcontribs)

It will be displayed in articles as plain text (similar to what you'd see now if it were nowiki'd). And, yes, this is a very easy task for a bot.

There is a fairly long series of similar changes being planned for this year. Some are easily fixed by bot (assuming that your wiki has a bot and an operator willing to do this; not all of them do), and others are not (e.g., wikitext tables that are missing the closing |} tag).

Tacsipacsi (talkcontribs)

Thank you for clarifying. This very wiki (huwiki) has quite a number of bots, so fixing here won’t be a problem. (talkcontribs)

The {{#if parser functions have no effect on MediaWiki whatsoever because they are not part of it, and are merely added by an extension. A true boolean should leave no room for ambiguity, and currently users are simply making up their own definitions of true and false, which again doesn't exist in wikitext.

So, giving it more thought, the lesser evil here would probably be introducing the notion of boolean to mediawiki wikitext. Or at the very least to Wikimedia, it would be trivial for them to add new global magic words / parser functions for true and false. Like so:

{{+}} - > true 
{{|}} - > false
{{mytable | border = {{+}} }}
{{mytable | border = {{|}} }}

As both + and | are invalid characters in page titles, this would work seamlessly, and it can transclude whatever truthy values people expect, although some other characters could be used.

It would remain backward compatible even with lua, and would probably encourage users to use a much saner symbol for true and false. It also wouldn't need any i18n, because these are just symbols, and have no meaning aside from what people assign to them.

Making false explicit is always superior to automatically assigning it when a string doesn't exist.

TheDJ (talkcontribs)

I realize this case looks a lot like a traditional boolean, but it's more like a "defined" vs. "undefined".

So in wikitext, we only have defined vs undefined, which is actually closer to true booleans than anything else we have in wikitext. On top of that we built boolean values, which are basically 'template specific' and as such don't truly exist in wikitext, yet that not existing element seems what we are trying to model in VE templatedata.

It's logical that this causes us to run into some problems. We have to remember however that this is a common case, simply because it is more readable to write: {{table}} and {{table|border=y}} than it is to write {{table|border=0}} and {{table|border=1}}. I thus think that we probably need to be a bit smarter about this in TemplateData. Maybe boolean can be a subtype that is a specific version of: defined with a value and undefined with a default. (talkcontribs)

It is true that this is more like defined vs undefined. It doesn't however change the fact that the graphical interface has to somehow represent those 3 states. Not selecting anything in some templates may be equal to "true", and adding text may be false. It wouldn't be surprising if some wikipedias treat this as the norm, considering that some languages write from right to left, and others from top to down, which is an odd concept for some.

So despite all the alternatives presented here, it seems like a deliberate spec (1 /0) is certainly the superior approach, and that the developers made the right call and shouldn't change or augment it. As JDforrester noted, attempting to treat true and false as it works in the parser function may fix a lot of templates but may break even more.

Perhaps an alternative is a deliberate enum like templatedata construct that allows options like "values = {"yes" = "y", "no" = y}". (talkcontribs)

>"values = {"yes" = "y", "no" = ""}".

Reply to "Could use another boolean type"

Problem with this extension

Summary by Tacsipacsi
DavidL (talkcontribs)

Currently when clicking edit on a template, the TemplateData header appear some 0.5 or 2 seconds after the edition page is shown, making scrolling down the editing area. The effect is that when trying to mouse-click on the edit area, we instead click on the button that appeared while clicking.

Please, fix this problem and reserve some space for the extension header before it appears, so wiki editors can click on the edit area.

Whatamidoing (WMF) (talkcontribs)

Do you have this problem when you use Safemode to edit the page?

DavidL (talkcontribs)

Yes. I have the same problem when using safemode=1 in the URL.

Whatamidoing (WMF) (talkcontribs)

Which wiki are you editing at?

DavidL (talkcontribs)

I'm editing on fr.wikibooks.org mainly, but it occurs on every wiki projects.

Tacsipacsi (talkcontribs)

It happens everywhere, and there’s already a Phabricator ticket for it. I uploaded a short screencast demonstrating the issue on Phabricator.

Reply to "Problem with this extension"

Proposal for new data type

Summary by Tacsipacsi
片割れ靴下 (talkcontribs)

Dear everyone:

I'd like this to be provided list type. For example, first parameter of en:Template:Medal or ja:Template:Medal can be set following string:

  • Gold, G
  • Silver, S
  • Bronze, B
  • Winner, W
  • Runner-up, Runnerup, RU
  • First, 1st
  • Second, 2nd
  • Third, 3rd
  • Disqualified, DQ
  • TrueSpirit, PdC
  • Olympics, Olympic
  • WorldChampionships
  • EuropeanChampionships
  • Competition, Comp, Sport
  • Team
  • Country
  • Independent

It will be convenient to be fill in with pull down menu. It will be more convenient if display string value to be set and its description together.

Best regards, unpaired sock.

Tacsipacsi (talkcontribs)

List has already been proposed at phab:T53375, but now I mentioned your suggestion of labels over there.

片割れ靴下 (talkcontribs)

Thank you for your information! We wait new awesome feature!

Reply to "Proposal for new data type"
Amire80 (talkcontribs)

What is the difference between the "string" type and the "line" type?

Thiemo Kreuz (WMDE) (talkcontribs)

In VisualEditor, "line" will create a single line OO.ui.TextInputWidget that doesn't allow line breaks, while "string" will create an OO.ui.MultilineTextInputWidget. However, if a value already contains a line break, the type "line" will be ignored to not destroy the value.

Does this help?

Amire80 (talkcontribs)

Yep! Thank you!

Tacsipacsi (talkcontribs)

@Thiemo Kreuz (WMDE): I recall VE destroying line breaks of a parameter. Maybe I recall it incorrectly, maybe it’s a bug fixed a long time ago, but it’s worth using line only when it’s absolutely sure it won’t contain line break ever (e.g. usually one-line infobox fields can contain multiple values separated by line breaks or multi-line references).

Reply to "String vs line"

The Description fields are all expanded in my TemplateData views

WikimeSteve (talkcontribs)

The Description fields are all expanded in my TemplateData views. The whole thing works fine so I think this is just cosmetic but the way they look on Wikipedia is nicer. The pages are generally exported from Wikipedia and imported so the same source. All pages everywhere that this is used show the empty fields.

This is how the same TemplateData shown on Template:TemplateData header appears on MediaWiki:

I would like to have the same appearance and suspect I have missed some CSS or a setting somewhere since the page content is identical.

Whatamidoing (WMF) (talkcontribs)

I think you're on the right track, but I can't remember the details. Let's see: @TheDJ, @Izno: do either of you remember something about hiding the empty fields a while ago (maybe earlier this calendar year)? I'm pretty sure that we changed something to make it more compact, but I'm not sure if the fix was CSS or a change to the software.

Izno (talkcontribs)

A little searching found phab:T125333 which appears to be a PHP change. It was deployed in 1.32/wmf.24 and presumably in the 1.32 release.

Reply to "The Description fields are all expanded in my TemplateData views"