Extension talk:TemplateData

Jump to navigation Jump to search

About this board

inserting images/files in templates in the new wikipedia editor

4
Elastano (talkcontribs)

is shit. the software should recognize when file names have to be wrapped inside some wiki markup in order to be shown correctly. for example, if i try to insert the filename of a screenshot into a page that is using an infobox with a "screenshot=" field, it should at least alert me that this field expects something like File:Xy.png and maybe offer text completion instead of just saving the wrong string that just shows text after saving.

Tacsipacsi (talkcontribs)

This is neither the responsibility of TemplateData nor of the visual editor. These are just tools for storing and presenting template documentation; the on-wiki template documentation should make it clear what format the parameters should use (and stop using “file” data type if it does now, as that‘s clearly for bare-filename parameters).

Elastano (talkcontribs)

interesting. so you think it can be made to show all the wished behaviour i described above with just the right code in the template documentation?

Tacsipacsi (talkcontribs)

Of course it’s possible to say in the human-readable description field something like “The screenshot using the normal ‘[[File:filename.jpg|250px]]’ image embed syntax.” It’s not possible, however, to convert just the file name automatically into a file link, as that contains arbitrary options in addition to the file name, like the desired width. (By the way, if you save the page without checking the preview, that’s your problem.)

Reply to "inserting images/files in templates in the new wikipedia editor"
Zackmann08 (talkcontribs)

Is there any way to edit this information basically in a spreadsheet? It would just be really nice to basically go down the list updating fields. So I know that I want to set the type for fields. Rather than opening each param individually and setting the type, I could just work my way down the rows setting the values. Even an option to export/import to a CSV would be wonderful!

Whatamidoing (WMF) (talkcontribs)

I'm not aware of any existing script for this, but the end result is standard JSON, so it is theoretically possible.

Reply to "Edit in table format"

Options to select different date formats

14
George Ho (talkcontribs)

I was given a suggestion at Topic:Unpy3y332x9rk1ji that I request some change on TemplateData to allow users to select different date formats. Here I am suggesting this especially for consistency with Wikipedia articles.

The current default format is "YYYY-MM-DD". I hope that the calendar feature would allow "DD Mon Year" and "Mon DD, Year" someday. If that is too complicated, alternatively, I made a suggestion there that an editor should have an option to manually type a date in a date parameter, similar to UploadWizard's.

Whatamidoing (WMF) (talkcontribs)

This function already exists at the English Wikipedia, and some other wikis that have up-to-date copies of the CS1 modules. If you combine |date=2018-11-20 with |df=dmy, then it will automagically display the specified date format to the reader. Better still, this parameter is something that could be added via AWB or bot to every citation template in every article that has the {{use dmy dates}} template in it, and the corresponding codes could be added for other date formats. Then editors wouldn't need to switch back and forth between formats when editing different articles, or to specify anything manually.

George Ho (talkcontribs)

I see that it works on "date" parameter but not "accessdate" parameter; see this diff. BTW, scrolling down to see the "Date format" parameter amongst the "Optional parameters" column can be a pain; the column is very long.

EDIT: I re-tested the "URL access date" parameter; I realize that the auto date formatting is not supported for that parameter.

George Ho (talkcontribs)

I'm becoming annoyed that the calendar sub-feature won't allow inserting of month and year without day for monthly magazines.

197.218.93.56 (talkcontribs)

Whatamidoing: It won't solve the underlying problem. The issue is that it relies on ISO date which is deliberately limited. For instance it can't record any historical dates before the 1800s. The primary concern is that for a tool that is meant to serve multilingual wikis it fails to address the fact that there are several calendars (e.g. arabic, etc) currently in use around the world. It would be perfect if there was a single unambiguous calendar to denote all existing dates (both ancient and current), but such a convenient system doesn't exist. Dates are really complicated concepts.

George Ho: This extension is a bit like a documentation manual, it only specifies how things must work but it can't do anything to actually require that tools that implement it work that way. So while it certainly needs a way to determine how to format dates, or even specify different calendars it is up to each editing tool to implement it properly.

However, the request for adding just month and year needs to be logged in the specific extension talk page or the bug tracker because the ISO standard already supports it.

George Ho (talkcontribs)

You mean separate "Topic", right?

197.218.93.56 (talkcontribs)

Yes, either that or by following Bugreport, and reporting it to phabricator.

Whatamidoing (WMF) (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

> it relies on ISO date which is deliberately limited. For instance it can't record any historical dates before the 1800s.

True, but it's unlikely that websites, magazines, and news articles from the 1700s or earlier will be commonly cited on Wikipedia, right? ;-)

197.218.89.48 (talkcontribs)

Err, the principle of an encyclopedia is documenting historical events. Wikipedia has distorted that and basically become triviapedia as well as futurepedia, but even if one wants to talk about current events, it is easy to find cases that don't neatly fit into the Gregorian calendar, e.g. this article (https://bn.wikipedia.org/wiki/%E0%A6%AC%E0%A7%8D%E0%A6%AF%E0%A6%BE%E0%A6%B8%E0%A6%A8%E0%A6%97%E0%A6%B0).

Feel free to try and explain how one would go about adding that date using the inflexible ISO. The same applies to historical dates on pages like https://lrc.wikipedia.org/wiki/%D8%B5%D9%84%D8%A7%D8%AD_%D8%A7%D9%84%D8%AF%DB%8C%D9%86_%D8%A3%DB%8C%DB%88%D8%A8%D9%8A.

Also, while the gregorian calendar is in the year 2018, the arabic calendar is current somewhere around 1441 (according to google). So recent news articles can demonstrably contain dates earlier than 1700.

The suggestion here is legitimate even if developers don't have the time or interest to implement it.

Whatamidoing (WMF) (talkcontribs)

Even if you managed to find a website from the 1700s, most Wikipedias would discourage citing it.

197.218.88.14 (talkcontribs)

Either you're wildly confused or you simply don't understand what's being asked here. Some views seem to include:

  1. Emphasis on citations. Dates aren't only used in citations, they can be used in descriptions boxes containing a person born 1000 years ago, or in a quote template or in any number of near infinite use-cases.
  2. The notion that most Wikipedias use the gregorian calendar when citing current events. It is mostly irrelevant. A template can express dates using any calendar or even using localized digits.

The world doesn't revolve around English or even latin based calendars. To give a concrete example, today's date is 2018-11-13 (gregorian) === Rabiʻ I 5, 1440 (arabic calendar). There is nothing wrong with citing an event today, and state that it happened in 1440 nor is there anything wrong in citing the date using localized digits or calendars.

Introducing extra calendars to templatedata would resolve most problems remaining problems.

Whatamidoing (WMF) (talkcontribs)

This feature is almost never used outside of a particular set of citation templates.

197.218.88.14 (talkcontribs)

The fact is the parameter was about as useful as bullets without a gun, all it did was document that a particular parameter accepts dates. Only recently, did it get some use by way of templatewizard. There are also more than 300000 templates (see https://en.wikipedia.org/wiki/Template:Infobox_product/doc) currently using dates, along with a similar a hacky {{xxx|month|year|date}} format, that's without even counting uses outside the bigger wikis.

There was simply no motivation for anyone aside from bored users to add that templatedata definition to templates. The notion that it won't get used because it wasn't used before makes no sense. Guns didn't get used before they became available, now some people have gone as far as claiming that it is some sort of human right to wield such things.

Reply to "Options to select different date formats"

Partial dates should be supported

5
Summary by Jdforrester (WMF)
George Ho (talkcontribs)

A monthly magazine, like Vibe and Men's Health, uses just month and year. Some, if not many, academic journals don't use full date, e.g. this one, that one, and another source that uses season and year (but can't think an example at the moment). However, the TemplateWizard currently wouldn't allow insertion of partial date; instead, either inserting full date and leaving a "date" parameter blank are the only available options to me.

If partial dates, e.g. month-year or season-year, are to be supported, I would appreciate it. Thanks.

Ciencia Al Poder (talkcontribs)

How about marking that parameter as plain text instead of date?

George Ho (talkcontribs)

Either I think I almost forgot that, or I've not clarified well. Either way, I should say that there's an option to insert the parameter without filling in anything in the TemplateWizard but then filling the paramater manually.

197.218.93.56 (talkcontribs)

Err, partial dates are already supported by Templatedata because it supports ISO_8601. TemplateWizard, and the related mediawiki widget would have to support it if deemed useful. See the linked wikipedia page for examples.

Of course if this is fully implemented in templatewizard or visualeditor then editors must prepare themselves for very weird dates. Stuff like --11-09 and 2018-313 or 2018-W45 is perfectly acceptable with iso, according to that page.

George Ho (talkcontribs)

Confusing, could use an overview and links to examples

2
Summary by 197.218.80.205
Skierpage (talkcontribs)

(Hi!) I was struggling over on Lyrics.wikia with all the MediaWiki markup in their page skeletons when all you really want is to enter some data {{band: "Corduroy", album: "Out of Here", song:"Mini"}} and have a song template produce the markup. It seems like TemplateData could really help, so I came here to remind myself about it. Alas the extension page lacks a simple explanation of how TemplateData interacts with actual templates, nor does nor does it give examples of it in use. The page says "This information is available as a nicely-formatted table for end-users", but my recollection is the stuff you put in the template data is somehow made available to other templates for them to output in their chosen wiki markup. There's a conceptual piece missing (or a screw loose in the reader...).

Whatamidoing (WMF) (talkcontribs)

TemplateData doesn't affect how the template behaves. It only tells VisualEditor which boxes to show when you insert a template.

Reply to "Confusing, could use an overview and links to examples"
קיפודנחש (talkcontribs)

one of the oldest, and widely used parser function is #switch

when a template uses a parameter as feeder to #switch, templatedata should be able to list the "legal" values, and also allow indication whether the #switch expression has #default clause, so a wizard will be able to provide a drop-down with the values, and optionally make it a "drop down combobox" which allows the user to feed a value not in the list.

if such syntax already exists, and it's only my ignorance speaking, please teach me. otherwise, please add switch property (call it whatever - html uses "select" and "options" i think), e.g.

"params": {
  "bla": {
    "description": "bla bla bla",
    "switch": ["preset value 1", "preset value 2" ...],
    "other": true
  }
}

peace.

Whatamidoing (WMF) (talkcontribs)
קיפודנחש (talkcontribs)

no. i'd like to see phab:T144155 also solved, but it's not the same issue.

in hewiki, we have "template wizard" since circa 2012, so it predates templatedata. we created our own "metadata" spec, which supported both the "boolean" attribute in the ticket, and a "select" attribute. the UI would present a checkbox for "boolean -like" parameters - selecting it would set the parameter to the prescribed value defined by the metadata. we had a separate "select" attribute, with "options" values, which behaved much like html "select" - the input field for such parameter was a drop-down listbox, so the editor would select one of predefined values, instead of a free text field as is with "normal" parameters.

some time after the introduction of templatedata, we modified our wizard to use templatedata instead of our "proprietary" metadata format, but we are missing the lost functionality, as described above.

peace.

Whatamidoing (WMF) (talkcontribs)
קיפודנחש (talkcontribs)

I am. I even left him a love letter on his talk page on enwiki a while ago. Twisi, his wizard is crippled by not being able to digest an existing template on the page, so it's a one-shot thing: get it right the first time, or you're on your own. My old wizard is ugly, but better behaved. Peace.

Reply to "select"
קיפודנחש (talkcontribs)

it is very disappointing, and IMO should be considered a bug, that templatedata does not support scribunto. there should be an established scribunto library that let me consume "templatedata" of a given template from my lua module (return nil or empty table if template does not exist or does not have TD).

scribunto is used mainly with templates, and the ability to consume templatedata should be considered elementary. User:Anomie explains that it is in the responsibility of each extension to generate the linkage library. see phab:T107119 - open since 2015.

currently, we plug this deficiency by executing the following abomination ("docSubPage" is predefined, to the "ducumentation" convention name of the specific wiki):

local function _readTemplateData( templateName ) 
	local title = mw.title.makeTitle( 0, templateName )  
	local templateContent = title and title.exists and title:getContent() ''-- template's raw content''
	local capture =  templateContent and mw.ustring.match( templateContent, '<templatedata%s*>(.*)</templatedata%s*>' ) ''-- templatedata as text''
''--	capture = capture and mw.ustring.gsub( capture, '"(%d+)"', tonumber ) -- convert "1": {} to 1: {}. frame.args uses numerical indexes for order-based params.''
	if capture then return pcall( mw.text.jsonDecode, capture ) end
	return false
end
local function readTemplateData( templateName )
	if type( templateName ) == 'string' then 
		templateName = { templateName, templateName .. '/' .. docSubPage }
	end
	if type( templateName ) == "table" then
		for _, name in ipairs( templateName ) do
			local td, result = _readTemplateData( name ) 
			if td then return result end
		end
	end
	return nil
end

please follow the instructions (here), and be done with it.


peace.

Whatamidoing (WMF) (talkcontribs)

Realistically, the priority level on that patch means that the team will cheerfully accept patches written by others. If you are waiting for the team to do this themselves, then I don't think this will happen any time soon.

קיפודנחש (talkcontribs)

i responded on phabricator back when.

the priority level of this ticket is grossly wrong. you guys need to jack up this priority. see, e.g., how many people subscribe to the ticket (look at the dupes also!) this is elementary - every extension that adds to the API, where it makes sense, should make it accessible to scribunto. it's hard to think of anything _more_ relevant to scribunto than templatedata.

peace.

Whatamidoing (WMF) (talkcontribs)

The priority level is meant to accurately communicate the team's actual intentions. In this case, AFAICT they don't mean to work on it during at least the next year. Reasonable people might disagree with their decision, of course, but the level marked in the ticket is meant to communicate that decision.

I'll ask the product manager to re-consider. To be candid, I don't have much hope for a change. The team is not focused on adding new features to TemplateData. Realistically, I expect they'll say that if the Scribunto people want to use TemplateData, then the Scribunto people need to write the patch.

קיפודנחש (talkcontribs)

in view of this comment, you can interpret my comment about "the priority level of this ticket is grossly wrong" to mean "the team's intention is grossly misguided"...

we are not talking here about "adding new features". twisi, it's about fixing a bug.

the thorn here touches the question who are those "scribunto people". the simplest interpretation is that "the scribunto people" are the community members writing modules in lua, in the different wikis, and often share/import those modules from one wiki to another.

these are decidedly different group of people from the group who create the mw libraries _available_ to those modules.

for instance, the wikidata team created an interface library enabling lua modules access to wikidata database, which proved to be very very successful. the people who created this interface library _are not_ generally thought of as "the scribunto people" - they are "wikidata people", but thanks to this interface' "the scribunto people" can now write modules that utilizes wikidata.

in a similar fashion, "the templatedata people" should write the interface library betwixt their stuff and scribunto.

tagging User:Anomie, hope to hear his take on which people should do what.

peace.

Anomie (talkcontribs)
tagging User:Anomie, hope to hear his take on which people should do what.

As was mentioned, anyone who wants to could submit a patch. The problem is finding someone who wants to, and has the necessary skills, and has the time to do it.

You're welcome to try to convince a WMF team to take it on, but if they say no then you may have to accept that answer. You're also welcome to work out how to do it yourself and submit a patch, or to convince a third party developer to write and submit a patch to your specifications.

Reply to "scribunto"
Samwilson (talkcontribs)

Is there an existing Javascript library (outside VisualEditor etc.) for parsing the TemplateData format syntax? Wanted for TemplateWizard (task T186653). @cscott: are you someone to ask about this?

Cscott (talkcontribs)

The implementation in Parsoid starts around here:

https://github.com/wikimedia/parsoid/blob/master/lib/html2wt/WikitextSerializer.js#L510

and the specification is

https://github.com/wikimedia/mediawiki-extensions-TemplateData/blob/master/Specification.md#37-formatstring

I think the entirety of the parser is basically this:

var FORMATSTRING_REGEXP =
  /^(\n)?(\{\{ *_+)(\n? *\|\n? *_+ *= *)(_+)(\n? *\}\})(\n)?$/;

var formatStringSubst = function(format, value, forceTrim) {
  if (forceTrim) { value = value.trim(); }
  return format.replace(/_+/, function(hole) {
    if (value === '' || hole.length <= value.length) { return value; }
    return value + (' '.repeat(hole.length - value.length));
  });
};
Samwilson (talkcontribs)

Thanks! That's brilliant info. :)

Reply to "Parsing custom formats in JS"
XanonymusX (talkcontribs)

I have read that it should be possible now to define a custom format, but I cannot find any information about how to do that on the page. Does it still need to be updated?

Jdforrester (WMF) (talkcontribs)
XanonymusX (talkcontribs)

Thank you for the link! So now I have a concrete question about the format: in my case, the template is a combination of unnamed (thus, numbered) parameters, which should always be inline, and named parameters, which should be formatted as block. Is there any possibility to specify separate formats for selected parameters in TemplateData? I am thinking of a potential combination of paramOrder and format, or something like that.

Jdforrester (WMF) (talkcontribs)
in my case, the template is a combination of unnamed (thus, numbered) parameters, which should always be inline, and named parameters, which should be formatted as block. Is there any possibility to specify separate formats for selected parameters in TemplateData?

No. This sounds like a very odd use-case. I would strongly discourage this pattern of wikitext.

XanonymusX (talkcontribs)

Besides the fact that this might be used much more frequently than one can think, there simply is no other way, because having a list of short unnamed parameters as a block makes the source look ridiculous; at the same time, however, inline is no solution, as the long list of other parameters would make the source unreadable if put on one line. Certainly, the better of the two is block, so other users will just have to correct the source by deleting the unnecessary breaks, which seems like an easy task. A possibility to define the format correctly already in TemplateData would however be much appreciated.

XanonymusX (talkcontribs)

Actually, I just tried it, and it seems that the unnamed parameters will be put inline automatically, even if block is specified! In that case everything is fine!

Whatamidoing (WMF) (talkcontribs)

Can you give an example of this? I don't remember seeing it before.

XanonymusX (talkcontribs)

Well, the use case is de:Vorlage:Charttabelle. TemplateData is of course not able to follow the usual order of the parameters in the example given, but at least it leaves all the unnamed parameters in one line.

Jdforrester (WMF) (talkcontribs)

I don't understand. TemplateData is definitely able to write out in the order of parameters, except that templates's TemplateData block is invalid so it won't work. If you click "Vorlagendaten verwalten" to load the editor, it will warn you:

Ungültiges JSON-Format. Du kannst diese Operation zum Korrigieren abbrechen, die aktuellen <templatedata>-Tags löschen und es erneut versuchen oder mit dem Ersetzen der aktuellen Vorlagendaten durch neue fortfahren.

I'm not quite sure how you've managed to save past the error. The TemplateData block lacks the customary whitespace which makes reading it hard, and the descriptions try to use wikitext which won't work, but I'm running between meetings so I can't see how to obviously fix it.

XanonymusX (talkcontribs)

That has nothing to do with this template, but with de:Vorlage:TemplateData, which makes the Vorlagendaten-verwalten button useless (not my invention). The TemplateData works fine with this template (except obviously for tasks T52407 and T178341 that need to be solved in order to actually allowing the use of the complete template in VE).

But let me give you more detail. The usual parameter order of this template is (traditionally) the following:

{{Charttabelle

|DE|AT|CH|UK|US|Quellen =

| Art =

| INHALT =

}}

TemplateData currently makes it look like this:

{{Charttabelle|DE|AT|CH|UK|US

|Quellen =

| Art =

| INHALT =

}}

In the end I do not mind, it still makes sense.

Jdforrester (WMF) (talkcontribs)

Well, if the editor hadn't been broken, I would say "just drag the parameters into the order they should be in and they'll be saved that way", but of course it's not helpful. :-(

Maybe that meta-template can be deleted?

XanonymusX (talkcontribs)

I have now changed the order (which is working absolutely fine, just edit Vorlage:Charttabelle/Doku)! :) But what I actually meant with order was the predefined position of some parameters in the traditional use of the template as shown above. I really do not like to have the unnamed parameters in the same line as the template name, but I can live with it.

I doubt that the meta-template will be deleted, even if it was heavily criticised just some days ago. It is already used quite a lot and I have to say that I like the visuals of it, otherwise I would not have used it for my template.

Whatamidoing (WMF) (talkcontribs)

PerfektesChaos, do you have any idea what the JSON problem is with Vorlage:Charttabelle?

PerfektesChaos (talkcontribs)

Showing up incidently today.

No idea at the first glance, but it seems to me the local German de:WP:VWS would have been a faster and more specialised help desk ttan internnational stage.

I'll continue on loval level and solve the problem over there; may be regarded as "solved" here.

Reply to "Custom format"
197.218.84.226 (talkcontribs)

Use case

As a user, I'd like to guide and validate user input so that each input is always valid.

Background

Input masks provide a way to validate and indicate the exact format of the data entered, for example:

  • Telephone - (___) ____ ____
  • Zip code - ___ ____
  • email, barcode, ISBN, color codes, etc

A good example of this is microsoft word inputmasks or alternatively actual html5 patterns. While it is possible to implement this for each of those, there are an infinite number of ways to require input.

Proposed solution:

Add a new field(s) to templatedata that governs the exact input. For example:

<templatedata>
params": {
    "phone": {
            "label": "Phone",
            "type": "number"
            "inputmask" : "(000) 000-0000",
            "usemask-output" = "false"
     },
}
</templatedata>

Once the page is saved, the input is normalized to the basic wikitext, e.g. "phone = 123123123", and vice versa when the template dialog is loaded. Alternatively, for certain templates it could output it as shown when using the usemask-output parameter.

Whatamidoing (WMF) (talkcontribs)

I don't think that this has been considered before. The team is still wondering when it might be safe to start enforcing much simpler things, such as fields for URLs not containing non-URLs, fields for files not containing non-File: links, etc. This looks like a step well beyond that point.

197.218.88.91 (talkcontribs)

The enforcement should probably be the default, as long as there is a fallback to override it. For instance, probably 80%+ of the world's population has no clue what an ISBN is or what the exact length of it should be.

This would probably resolve a lot of issues that end-users have. There is a often limit to the exact amount of text allowed by most parameters, as such any user adding more than that is likely not inputting it correctly.

Side note: Apparently the page on Input mask did not contain even a single reference (before I added it). Maybe if the editing tool had input masks, more editors would actually know what to add there and how :).

Reply to "Suggestion: Provide input masks"