Extension talk:TemplateData

Jump to navigation Jump to search

About this board

Cannot add complete/concise TemplateData to templates that accept many numbered parameters

2
Summary by Thiemo Kreuz (WMDE)
Sdkb (talkcontribs)

For templates like w:Template:Multiple image and w:Template:Maplink, there can be an arbitrary number of parameters for images in the collage or points on the map. TemplateData does not currently seem to have a way to handle this; the best that can be done is to add TemplateData manually up to a dozen or so, which covers most use cases. However, this is tedious, first of all, and it clutters the documentation by creating a bunch of repetition. There are a lot of templates like this, so I'd like to see this fixed at some point.

Thiemo Kreuz (WMDE) (talkcontribs)

Yes, this is a known limitation, see phab:T54582. I'm afraid there are currently no plans to work on this.

Reply to "Cannot add complete/concise TemplateData to templates that accept many numbered parameters"

Small bug with warning message

6
Summary by Whatamidoing (WMF)
Sdkb (talkcontribs)

When I edit a template that has a TemplateData block on its documentation page, a warning appears ("Please note: there is already a TemplateData block on the related page"). However, when I edit a section of the documentation when there is already a TemplateData block in a different section, no such warning appears. This isn't the biggest issue, but it'd be nice to rectify. (It'd also be nice if, instead of a distracting warning, clicking on the button just redirected you to edit the documentation page; this would reduce both banner blindness and errors.)

Whatamidoing (WMF) (talkcontribs)

I think I've followed all of that, but could you give me a link so I can try it out?

Sdkb (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

Right now:

  • If you edit the 'wrong' page, it warns you that TemplateData is present on the 'right' page.
  • If you edit a section of the 'right' page, it does not warn you that TemplateData is present in a different section of this page.

You propose:

  • (No change for the first point)
  • Adding a warning that TemplateData is present in a different section.

I wonder if this might be more annoying overall. There are almost 50 sections on that /doc page. I imagine that most people aren't trying to change the TemplateData (unless they're editing the TemplateData section itself). I think adding this warning might produce complaints about an "irrelevant" warning. I can imagine editors saying "Why is it telling me that TemplateData is in another section? I already know that! If I cared about TemplateData, I'd be editing the section named ==TemplateData==!"

Sdkb (talkcontribs)

Yeah, I think that speaks somewhat to my point in the parenthetical above. There's no strong need to have it at the main template, either; editors could make a similar point about it being irrelevant there. Instead of the existing workflow, I think it would be better if there was initially no warning, but if someone clicks the Manage TemplateData button, a notice pops up saying "There is already a TemplateData block on the documentation page/in another section. Click proceed to edit it there (you will lose any unsaved work)." That would be better since it'd then only affect people actually trying to edit the TemplateData, so the banner blindness would be significantly reduced.

Tacsipacsi (talkcontribs)

The proposed solution with the TemplateData editor adding the warning (instead of the static warning banner) looks good, with one exception: if someone adds a TemplateData block manually, without the wizard, they’re not warned. Probably this use case is rare, but possible; for example importing TemplateData from another wiki/page is much more convenient using copy&pasting wikitext than with retyping everything in the wizard.

Reply to "Small bug with warning message"
Sdkb (talkcontribs)

At least on the en-wiki implementation, the difference between "string", "line", and "content" is not particularly clear, and the documentation table doesn't help very much. Would it be possible to clarify it further?

Thiemo Kreuz (WMDE) (talkcontribs)
Sdkb (talkcontribs)

Thanks! I still don't feel like I have a full sense of things (maybe some examples could help?), but the line breaks note is definitely an improvement. Good luck with your work on this!

Whatamidoing (WMF) (talkcontribs)

The words "String" and "Line" mean whatever those words mean to coders. "Content" means what an editor thinks it means (approximately "anything goes"). The distinction is mostly not enforced by software (yet, but I've been saying that for years, and I expect to be saying that years from now).

Reply to "Types unclear"

"One of several" type

2
Summary by Thiemo Kreuz (WMDE)
Sdkb (talkcontribs)

I was definitely pleased to see the suggested values feature rolled out. I think it might be helpful to also have a type for parameters that should be one of several values but nothing else. Sorta like boolean only for more than two.

Thiemo Kreuz (WMDE) (talkcontribs)

We are happy to hear you like it. A more strict version is still discussed in phab:T53375. For now the team decided to go with the most flexible version for a multitude of reasons. It already solves the vast majority of use-cases, without ever blocking anybody. You can find more about the reasoning in phab:T271825 and it's sub-tickets.

Reply to ""One of several" type"

After import, a template requires a manual re-save for TemplateData to work

2
MLRodrigue (talkcontribs)

When I import a template that uses TemplateData to another wiki, the template description and parameters are not shown when adding the template to a page via VisualEditor.

Noteː The parameters in question are either required or suggested, so should show up immediately when the dialog opens.

To make the template work, I have to go to the imported template and re-save it (e.g., by adding an empty space to the template page). After that, the template works correctly in the imported wiki and the parameters and template description are available.

Is this to be expected?


Such templates that use TemplateData are supposed to be imported by wiki users who have no access to maintenance scripts.

Tacsipacsi (talkcontribs)

As noted in Help:TemplateData#Limitations and feedback, a null edit is sometimes required for TemplateData to update. This can happen while importing as well. However, no actual edit (and thus no page history spam) is needed; and if you have Pywikibot set up, you can use touch.py to automate the null edits (this requires no direct shell access to the server).

Reply to "After import, a template requires a manual re-save for TemplateData to work"

Big task: Translating template content

2
Summary by Whatamidoing (WMF)

Off topic

BoldLuis (talkcontribs)

I tried to translate the content of the template w:template:Infobox organization in the article w:Open Source Security Foundation. I have to add to parameters by hand, related to location (in the Spanish version "ciudad de sede") and region (also "region" in the template in Spanish). Why?. I am going to try to find the reasons for this. Specially, when the field is called with the same name in both local templates.

Whatamidoing (WMF) (talkcontribs)

Translating a template documentation

3
Summary by Thiemo Kreuz (WMDE)

Not specific to this extension.

BoldLuis (talkcontribs)

Mediawiki TemplateData can be used to translate a template documentation. The worst: you have to copy from a Wikipedia to another Wikipedia, to see the documentation in the destination language.

I have done it in Wikipedia Template:Short description. I have translated the TemplateData from English to Spanish (you can edit TemplateData and select "español" -this is, Spanish- to see the translation into Spanish).

The problem: I have to translate the template documentation (TemplateData of the template) in the English Wikipedia and copy and paste it into the documentation page o f the template in the Spanish Wikipedia.

This is not good. The best idea is that I could see the translation in the Spanish Wikipedia, without copy and paste, in a Wikidata manner (global documentation from TemplateData).

Also, this translation into Spanish could be seen in Wikibooks in Spanish, Wiktionary in Spanish and so on, without copy and paste the TemplateData from the English Wikipedia to Wikibooks in Spanish, Wiktionary in Spanish and so on.

Thiemo Kreuz (WMDE) (talkcontribs)

I can only guess that you want to edit the documentation of es:Plantilla:Breve descripción. That's another template with it's own documentation. The MediaWiki software does not support global templates yet.

BoldLuis (talkcontribs)

Really it is support for documentation (translation of documentation). Avoid copy and paste several times (perhaps using Wikidata). If the TemplateData it is copied to another Wikipedia and a translation to a third language is done in this second Wikipedia, it is not enjoyed and used in the first Wikipedia. Inefficiency.

Odd Issues With Editing TemplateData In Visual Editor

3
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:

https://pastebin.com/0SsiJpje

https://pastebin.com/bqvX6tZT

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

dm/models/ve.dm.MWTemplateModel.js

----------------------------------

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

modules/ve-mw/preinit/ve.utils.parsoid.js

————————————————————

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.

modules/ve-mw/preinit/ve.utils.parsoid.js

————————————————————

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
206.55.182.254 (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

206.55.182.254 (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

13
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?

Thanks

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"