Why do not automatically appear parameters when editing templates in Wiktionary (using the "Edit Template Data" button, in the left corner when editing the template)?
Help talk:TemplateData
All TemplateData would include a link to Wikidata.
Why?
Because can be used in other projects.
Agree.
Without retyping all the data, fields an information.
I don't think I understand your suggestion. This is the TemplateData for the English Wikipedia's "citation needed" template:
<templatedata>
{
"description": "The template is used to identify claims in articles, particularly if questionable, that need a citation to a reliable source.",
"params": {
"date": {
"label": "Month and year",
"description": "Provides the month and year of the citation request; e.g., 'January 2013', but not 'jan13'",
"type": "string",
"autovalue": "{{subst:CURRENTMONTHNAME}} {{subst:CURRENTYEAR}}",
"suggested": true
},
"reason": {
"label": "Reason for citation",
"description": "A reason as to why, or for what content, the citation is needed; use single quotes, if any",
"type": "string"
}
}
}
</templatedata>
No editor or reader at any article ever sees that. I don't think it makes any sense to add a Wikidata link to the TemplateData.
Are you looking for a sort of magic infobox, so that you can type {{infobox}} and Wikidata fills in all the fields for you? That already exists, and it has nothing to do with TemplateData. Have a look at w:es:Jimmy Wales for an example of a long infobox that is mostly pulled from Wikidata.
From your example : "description": "The template is used to identify claims in articles, particularly if questionable, that need a citation to
It would be translated to other language, I e. Spanish:
"description": "La plantilla se usa para identificar afirmaciones en artículos (and so on...)
So, this translation into Spanis of the template can be used in Wiktionary in Spanish, Wikipedia in Spanish, Wikibooks in Spanish... Translate once, use in several places.
On the other hand, this is seen in a forms way, when editing TemplateData.
TemplateData editor method
This is the simpler way to add or edit TemplateData, possible for inexperienced users. </translate>
The TemplateData editor is a graphical user interface for adding and editing TemplateData. It is part of the TemplateData extension. It is accessible by going to any template's page (or documentation subpage) and clicking "Edit" or "Edit source".
After clicking "Edit" or "Edit source", you will see a button above the editing area and page title that says "Manage TemplateData".
Clicking this button will enter the TemplateData editor.
If the page you are on already contains TemplateData, this will automatically show here.
Because we don't have Global templates, it's unlikely that anything would get re-used in multiple places.
We can use TemplateData in Wikidata for templates in all sister projects and so, the template documentation can be reused in multiple sister projects. Translate once, reuse several times. Also could be used the Wikifunctions wiki.
This post was hidden by Tacsipacsi (history)
I recently fixed TemplateData on en:Template:Infobox organization but did not find an easy way to search for other potentially affected templates with errors, particularly high trafficl ones. Is there a tracking category for this? Shushugah (talk) 19:09, 13 September 2021 (UTC)
@Izno, do you have any recommendations for this? Does w:en:WP:CHECKWIKI handle this?
If by "fixed TemplateData" Shushugah means this set of edits, no, there is no way to detect this.
I've tried to add TemplateData to a template in my user space, but couldn't get it to work. To make sure the problem wasn't with my template, I copied an existing one that worked on enwp {{0}}, and found that it stopped working when I tried to place the TemplateData in User:username/templates/template/doc. Does TemplateData only work in the Template namespace? Thanks, ~~~~
Note that you also need to transclude the documentation subpage into the User template page for it to work, e.g.: {{m:User:ExE Boss/OtherProjects}}.
Thanks, yes, that's a good point, but I think I had that right: immediately at the end the last line of the template, I called had the documentation template embedded in a noinclude tag. The working template that I copied also did that, but stopped working in user space.
Right, I forgot to mention, that you also need to perform a null edit/hard purge of the User template page, in order to properly update the templatedata page property (the TemplateData extension does this automatically in the Template namespace when editing the doc[1] subpage).
References
It is always helpful to link to an example page when you are asking for technical help.
Thanks for helping everyone! It's fairly easy to reproduce: Copy the 0 template (I just chose that because its one of the first in the list of templates that use TemplateData) and its doc subpage to your userspace. Now try to edit your sandbox with the Visual Editor and add the 0 template. My version that demonstrates the problem is at en:User:Vexations/templates/PB
It doesn’t work in VisualEditor indeed, but it seems to be a bug in VE, not TemplateData: when I open your user subpage’s talk page in VisualEditor and try to insert the user subpage, no TemplateData is provided (and not even the title is visible in the autocomplete for the template name), while if I use the wikitext editor’s template inserter 
, it works perfectly.
Pinging @Johanna Strodt (WMDE), because this is probably not related to WMDE's work on templates in VisualEditor, but it might be useful to know about anyway.
Thanks @Whatamidoing (WMF). Agreed!
MW 1.35.0, TemplateData 0.1.2
I have templates defined using TemplateData. Filling in and editing these templtates works fine in Visual Editor (VE) up through the first save, for example this image, but upon subsequent edits it cannot find the template as shown here: it strangely believes that :index.php?title=Template:<Template Name> is the name of the Template page! Any thoughts
Hmm. A few questions:
- What does the "Generated from:" text show in the popup box for the template, when you commit the data edits in the Visual Editor (before you save)?
- What does it show after you save, then edit the page again?
- If you switch to Source Editing while you're re-editing the page, does it show the correct template transclusion, e.g.
{{Cite book|something=|something_else=|...}} - What is the URL format for your wiki? Like, what's the actual URL to Template:Cite book? What's the URL for the article you're editing?
On Wikipedia, Template:Cite book lives at https://en.wikipedia.org/wiki/Template:Cite_book.
So if I'm editing https://en.wikipedia.org/wiki/The_Cat_in_the_Hat and want to cite Dr. Seuss, the URL to Template:Cite Book has the same https://en.wikipedia.org/wiki/ prefix. Same for the article's edit interface, which loads from https://en.wikipedia.org/wiki/The_Cat_in_the_Hat?action=edit
But it looks like either your wiki is using old-style index.php?title= URLs and the Visual Editor is mishandling those, or something is configured to think the URLs should be index.php?title=-style when they're not. (Are there any rewriting rules / HTTP redirects configured on the wiki's web server, for article paths?)
I have the same problem. I just found a bug logged pointing at the no-usage of Short URL :
https://phabricator.wikimedia.org/T270219
They give some workaround.
I have just added $wgUsePathInfo=true; to my LocalSettings.php for it to work.
Ooh, good find @GeoffreyHfr, that bug clearly describes exactly the problem here. According to the info there, Visual Editor simply doesn't support index.php?title= URLs, period. Apparently it never has, since Wikipedia has used short URLs since long before Visual Editor became a thing.
(Might be nice if that was documented somewhere prominent, or if it had some way to detect those URLs and at least display a helpful error message. Still, at least now people have this bug to refer to, so that's something.)
so, wiki template syntax supports something called #switch.
the switch can have a "default", or not. when a parameter is _only_ used in a switch, and there is no "default", it means that only one of the suggested values will have any effect, and everything else is equivalent to no value at all.
the TD syntax should allow distinguishing between those two types of use. currently, the help page says
"If the user needs a value not included in the list (for example, "message in a bottle") they can type it in manually."
this makes sense for some parameters, and no sense for others (i.e., params only used in #switch with no default).
note that the TD is used by things other than the visual editor, for which this feature was requested for the longest time - see, e.g., phab:T224342.
peace
I’ve already brought up this issue at m:Talk:WMDE Technical Wishes/Suggested values for template parameters#Marking list as exhaustive.
Will TemplateData be used to document Lua? Can VisualEditor use TemplateData to give hints for module invocation?
Good idea!!!!!!
Are you meant to be invoking a module directly?
Good point, thanks! There's already a /doc subpage (e.g. [1]) for the module itself, and that's all we need.
It's the functions within a module which can be invoked from wikitext, these take parameters, and this is where we would need the structured documentation. I'm not sure how we could provide these docs (or maybe editors feel this is not lacking?). LDoc and maybe other syntaxes would be appropriate for inlining docs in the source code, but wouldn't cover our use case. We pass an opaque frame and it's the args arguments within that define the module's MediaWiki interface. We also need a way to indicate which functions are meant to be public.
Needless to say, however we (if we) decide on a syntax, it should be machine-parsable so it can be leveraged by VisualEditor and other tools.
Hello MacFan4000,
You have split several paragraphs in order to reduce translate tag use. I think this is a bad idea because this make the text harder to read. Indeed, those one-sentence paragraphs are really strange; beside this make some sections (especially introduction) very big. Would you see any inconvenience to come back to previous paragraph splitting?
I agree. Having slightly cleaner wikitext is not worth having a significantly less clean rendered output.
It is actually possible to split a paragraph into two translatable units without visual differences on the page.
In a template the default value of a parameter can be set to the value of another parameter. For example, parameter 2 can default to the value of parameter 1...
{{{2|{{{1}}}}}}
What is the correct way to represent this relationship in templatedata so that Visual Editor will handle the default properly? I've tried the approach below, but instead of showing the value of parameter 1 the template shows the number 1.
# This approach results in the wrong default behavior
# when the template is added with Visual Editor
<templatedata>
{
"params": {
"1": {…},
"2": {
"label": "optional value",
"description": "if this value is empty, show the value of parameter 1 instead",
"suggested": true,
"default": "{{{1}}}"
},
"paramOrder": […],
"format": "inline"
}
</templatedata>
My interpretation would be to indicate it as an alias.
Agreed. In the code shown above, 2= is an alias of 1=.
However, there are situations where an alias doesn’t work. Imagine a template that links to the English Wikipedia. Its code is
[[w:{{{1}}}|{{{2|{{{1}}} }}}]]—the first parameter (the article title) is required, while the second (the display text) is optional, and defaults to the article title. The two are clearly not aliases, but the default of parameter 2 is parameter 1. I usually write something like “parameter #1” to default and hope that the human reading it will understand what’s going on. Or describe the situation in description, and leave default empty. But neither of these workarounds is really a solution. Probably there should be a new key (mutually exclusive with default) that contains a parameter name (instead of literal text) the parameter defaults to. Support for this should be implemented in consumers like VisualEditor afterwards, of course.
This page explains that when you edit the TemplateData code, "If you have made errors, it will not let you save." How can this edit, which broke the TemplateData code, be explained then?
https://en.wikipedia.org/w/index.php?title=Template:Infobox_university/doc&diff=next&oldid=879525244
Can someone please clarify this documentation?
Simple. Hacky unexpected usage results in unexpected behaviour and breakage.
Someone made an error, and the page was saved with the error, which appears to contradict the statement I quoted above. I believe that this page's documentation should be clarified.
Judging by the tags on the edit, they edited raw wikitext of the page rather than using the specialized TemplateData editing tool. Thus their edit wasn't subject to its scrunity.
Thank you for the actual helpful answer! I have updated the page to reflect the difference between using the tool and using a wikitext editor.
That's the wrong answer. The hacky transclusion means that what's in the page is actually irrelevant. In fact the page content might have changed without any edit to the page.
That's clearly documented mediawiki behavior.
IP editor: Your explanation does not make sense to me. In the edit I linked above, an editor replaced the word "description" in the TemplateData code with the word "descriptiwon", which presumably caused the TemplateData error. I don't see any evidence of a "hacky transclusion" in that edit, but I might be missing something. If you have a better explanation that answers my original question, feel free to edit this Help page to clarify it. Thanks.
Err... The expected use of this extension is directly embedding the templatedata tag to the page. All templates or lua modules that override that behaviour are clear hacks(https://phabricator.wikimedia.org/T124338). Also you're wrong about the change, template transclusions were also added.
Perhaps you have an incomplete understanding of how templates work. Templates are entirely free to fully ignore all parameters used to call it. Or to parse them differently and output something different from the input.
So what was input was not necessarily what was output by the template. That coupled with the hacky use results in unexpected behaviour.
It will only be possible to fully prevent bad saves if/ when templatedata is moved to its own page like .CSS,.js and lua modules.
The last bit is something that you and I can firmly agree on. Storing programming code such as Template Data in an unprotected page that was designed to store template documentation is simply bad programming practice. I look forward to Template Data being moved to its own set of pages, which is something that should have happened long ago.
Raw text editing is much simpler and has more flexibility than any custom tools, and the errors are very visible and easily fixable.
It also allows for easy experimentation with new features, before a custom toolset is updated or even without the need to build one in the first place -- which is a dramatic time and effort saver.
Due to the above, the ability to edit raw data is seen as a strength of a wiki rather than a drawback.
The maximum use I see for encorcing syntactic correctness is to run a syntax checker before saving -- and again, it can only produce a warning rather than a hard error because there's a possibility that the user is trying something that the syntax checker doesn't know about.
I'd estimate that it would cost roughly US$250k of staff time to move TemplateData into an MCR slot now; most of that cost would be in making a lot of decisions about how MCR would operate, rather than specific to TemplateData itself. I don't think there's appetite for that right now, sorry.
As someone who donates roughly US$100K worth of volunteer time to en.WP every year, this answer leaves me a little cold. Discussing the cost of fixing a suboptimal programming decision is probably not the best approach to take with the volunteers who are left to deal with the consequences of that decision.
It wasn't a "decision". TemplateData (created in 2012–13) did not use MCR slots (created in 2017–2022) due to the polarity of time.
Yes, in retrospect, we could have foreseen this abuse and held up eight years of development, but all things must be weighed against each other. Similarly, the decision to create the #tag hack (made in ~2008) is the root cause of a lot of problems here, but it was also vital in helping editing communities establish things they felt that they needed at the time.
If you think that this is an important issue and worth the expenditure, I would encourage you to make your views known to the people that make decisions on this, but the people trying to help you on here aren't any of them, sorry.
I wonder whether the error-checking mechanism is looking for typos, or looking for valid JSON formatting. I'm guessing that it's the latter.
It's looking for schema compliance. So valid JSON, and valid against the TemplateData specification.