@eranroz Can you elaborate on what values should be shown from Wikidata? A few examples would be helpful. I see the birth date in the screenshot but I'm not sure how it determines whose birth date to auto-fill.

• The values that should be shown from Wikidata should be defined in the TemplateData. (example are birth date or birth place).
• The entity for which the data is filled is based on the entity connected to the current page (e.g wgWikibaseItemId )

If you build this feature, be sure to test it with weird edge cases like https://en.wikipedia.org/wiki/Bonnie_and_Clyde and https://en.wikipedia.org/wiki/Thomas_Jefferson.

Change 446978 had a related patch set uploaded (by Eranroz; owner: Eranroz):
[mediawiki/extensions/TemplateWizard@master] Wikidata support for TemplateWizard

https://gerrit.wikimedia.org/r/446978

In T199892#4436645, @eranroz wrote:

• The values that should be shown from Wikidata should be defined in the TemplateData. (example are birth date or birth place).

Okay, that makes sense.

• The entity for which the data is filled is based on the entity connected to the current page (e.g wgWikibaseItemId )

Can't it be that I'm trying to add a template for a user/object that is ambiguous from the page ID? An example is Wright Brothers article. It doesn't have the Wikidata data for birth dates but if it did, it would be ambiguous for the template purposes.
Also I'm 100% sure I have seen at least one wikipedia article with multiple person infoboxes but I can't find one at the moment.

In any case, I would like there to be a button which people click in order to import Wikidata values if they so choose. It shouldn't be automatically inserted for them.

Thanks for the patch, @eranroz! I'll check it out and talk to the project designer.

I was checking the OOUI widgets and some general UI patterns out there to see if there's a way to display this already.

As far as I can tell OOUI does not cover this yet except for placeholders (which is a different paradigm and thus probably shouldn't be used interchangeably) and I couldn't find anything else either.

If we do a suggestion it would be convenient to be able to add it with a click on it, instead of having to retype it.

The way you implemented it is a good solution I think. I would also like it to be in a way that you can add the value by clicking on it. Having it be added automatically if no value is entered could be a possibility for some communities if they decide they want this.

Feel free to come find me at the conference if there's anything I can help with.

Below are some more technical details/clarifications about the patch. Please skip the relevant section if you find it not relevant. (trying to address different audiences)
Expected usage
I assume that enwiki template (or a community that have less trust on Wikidata) would look like:

|Birth date || {{{birthdate}}}

(e.g - user should fill birthdate)
and cawiki (or a community that prefer to use Wikidata) would look like

|Birth date || {{#if:{{{birthdate}}}|{{{birthdate}}}|{{#property:P569}}}}}

(e.g if user doesn't fill, the data is pulled from Wikidata)

They will both have same template data and same UI in the template Wizard (see below):

<templatedata>
{
	"params": {
		"birthdate": {},
	},
	"maps": {
		"wikidata": {
			"P569": "birthdate"
		}
	}
}
</templatedata>

UI
The current implementation gives the following output (following click on the Wikidata icon)

Where the link of Capital City links to wikibase item (Wikidata) for the specific property for which we fetched the details from (such as https://www.wikidata.org/wiki/Q37610#P569 ).
Properties that aren't binded to Wikidata (such as "area" in the example), or that doesn't have Wikidata value filled for them (this will be the case for "bithdate" in the case on Bonnie and Clyde) doesn't have Wikidata icon.

As fetching the data from Wikidata is technically done in a separate web request, it may be loaded async - e.g after the template wizard have been shown. In such cases usually there are spinners to indicate not all the data already loaded - since here the load is opportunistic (only if there is Wikidata, and only if we found relevant statement in the wikidata item) I'm not sure spinner is required.

dev environment
For testing I'm running a dev environment with Wikibase extension installed with these settings (I mention it since running wikibase extension locally is somewhat non trivial to install):

$wgEnableWikibaseRepo = true;
$wgEnableWikibaseClient = true;

require_once "$IP/extensions/Wikibase/repo/Wikibase.php";
require_once "$IP/extensions/Wikibase/repo/ExampleSettings.php";
require_once "$IP/extensions/Wikibase/client/WikibaseClient.php";
require_once "$IP/extensions/Wikibase/client/ExampleSettings.php";

$wgWBClientSettings["siteGlobalID"] = 'enwiki';

after changing properties/items I run manually

extensions/Wikibase/repo/maintenance/dispatchChanges.php
maintenance/runJobs.php

A real production environment is expect to either have only wgEnableWikibaseClient (e.g only Wikibase client) or no Wikibase at all (e.g no wikidata)

Please be careful with cases like https://en.wikipedia.org/wiki/Template:Infobox_telescope - where the infobox fetches the information from Wikidata in a formatted way, rather than asking users to start putting things like {{#property:P569}} everywhere. It's very valuable to do the matching of wikidata properties against the fields using templatedata, so that we don't have to have manual tables that describe the info; and for users to be able to edit the Wikidata information directly or provide a local text override, but copying info from Wikidata or adding in extra tags to fetch Wikidata info should be avoided.

@Mike_Peel thank you for the comment. I totally agree that users shouldn't directly (e.g in the template instance, as opposed to the single template implementation) copy Wikidata value or use invoke {{#property}} directly.

This feature relays only on TemplateData and doesn't care on the implementation/actual visualization e.g:

1. Template may use Wikidata with {{#property:}} {{#statements}} or Lua module
2. Template may even not use Wikidata at all (in case some community prefer to use Wikidata just as "cross validation" or hint to compare to actual value)

The displayed hint from Wikidata is the simplest representation (e.g {{#property}})

@eranroz Thanks for the detailed explanation. Reading the ticket description and your comments above, here's my understanding so far:

Some wikis like to pull data directly from Wikidata if it's not specified in the template itself. While some other wikis prefer to use Wikidata for "cross-validation" or a hint. Can you explain a bit more on the second point? What's an example of when cross-validation happens using Wikidata?
Also, are there more ways in which people use Wikidata data for templates besides these two you listed?

About the implementation, T69659: TemplateData should have a parameter to support Wikidata is linked from the description as the data model but it seems like that task hasn't been completed. Is that a pre-requisite for this task?

For the second point:

• Example 1: cross validation template https://en.wikipedia.org/wiki/Template:WikidataCheck
• Example 2: (@Mike_Peel may know better how it works in enwiki - so please correct me if I'm wrong) In some communities such as enwiki there is/was no clear consensus to autofill parameters from Wikidata by default, and sometimes the prefered approach is two equivalent templates ([[Template:Infobox person]] and [[Template:Infobox person/Wikidata]]) and the user can decide to explicitly use /wikidata. In that case it may make sense to have wikidata mapping even in the non wikidata version, so user can verify the data is compatible before switching to /wikidata version.

As for T69659 - the patch handles it at least for the basic cases.

In T199892#4460347, @eranroz wrote:

• Example 2: (@Mike_Peel may know better how it works in enwiki - so please correct me if I'm wrong) In some communities such as enwiki there is/was no clear consensus to autofill parameters from Wikidata by default, and sometimes the prefered approach is two equivalent templates ([[Template:Infobox person]] and [[Template:Infobox person/Wikidata]]) and the user can decide to explicitly use /wikidata. In that case it may make sense to have wikidata mapping even in the non wikidata version, so user can verify the data is compatible before switching to /wikidata version.

It's complicated. The best thing would be to make it possible to have wikidata mapping if individual people working on the templates want it, but don't force all templates to have it. Note that even within one template, say one that mostly uses Wikidata information, there may be fields that *could* be matched to Wikidata, but aren't as they are controversial parameters (e.g., religion), or they are being deprecated (e.g., "weather" for telescopes). So the mapping should be optional and flexible.

In T199892#4466244, @Mike_Peel wrote:

In T199892#4460347, @eranroz wrote:

• Example 2: (@Mike_Peel may know better how it works in enwiki - so please correct me if I'm wrong) In some communities such as enwiki there is/was no clear consensus to autofill parameters from Wikidata by default, and sometimes the prefered approach is two equivalent templates ([[Template:Infobox person]] and [[Template:Infobox person/Wikidata]]) and the user can decide to explicitly use /wikidata. In that case it may make sense to have wikidata mapping even in the non wikidata version, so user can verify the data is compatible before switching to /wikidata version.

It's complicated. The best thing would be to make it possible to have wikidata mapping if individual people working on the templates want it, but don't force all templates to have it. Note that even within one template, say one that mostly uses Wikidata information, there may be fields that *could* be matched to Wikidata, but aren't as they are controversial parameters (e.g., religion), or they are being deprecated (e.g., "weather" for telescopes). So the mapping should be optional and flexible.

From my understanding the mapping happens in TemplateData and people who want it can have it.

Instead of providing a hint, like the current patch does, will it not be easier if we allow people to simply have those values in the input fields? It seems to me that in most of the cases, that is what the user would be doing. Instead of having to manually type in the information the 'hint' contains, we might as well allow them to fill that information in automatically. And then we ask them to verify if that looks correct and remove it if not. Does that seem like it would satisfy most of the use cases? Maybe something like -

Values in the input fields - Good idea, the mock-up looks nice, and this make me re-think that this way it is much more friendly than clicking for popup for each field.

Note that technically we don't want to copy the Wikidata value into the template instance. Example ([[Konrad Emil Bloch]]):
The template invocation should look like (as it is now):
{{Infobox person/Wikidata | fetchwikidata=ALL | onlysourced=yes|dateformat=mdy}}
and not
{{Infobox person/Wikidata | fetchwikidata=ALL | onlysourced=yes|dateformat=mdy|birth_date=January 21, 1912}}
so if the birth-date is wrong, and this is fixed later in Wikidata, it will be updated automatically in the article. (this is even more important for parameters that will likely change in the future even if they are correct such as population or mayor in Infobox settlement)

Hence if we use the input fields themselves we should either place the Wikidata values as placeholder, or have a kind of toggle button to let user decide whether to manually fill it

In T199892#4466925, @eranroz wrote:

Values in the input fields - Good idea, the mock-up looks nice, and this make me re-think that this way it is much more friendly than clicking for popup for each field.

Note that technically we don't want to copy the Wikidata value into the template instance. Example ([[Konrad Emil Bloch]]):
The template invocation should look like (as it is now):
{{Infobox person/Wikidata | fetchwikidata=ALL | onlysourced=yes|dateformat=mdy}}
and not
{{Infobox person/Wikidata | fetchwikidata=ALL | onlysourced=yes|dateformat=mdy|birth_date=January 21, 1912}}
so if the birth-date is wrong, and this is fixed later in Wikidata, it will be updated automatically in the article. (this is even more important for parameters that will likely change in the future even if they are correct such as population or mayor in Infobox settlement)

Hence if we use the input fields themselves we should either place the Wikidata values as placeholder, or have a kind of toggle button to let user decide whether to manually fill it

That's a good point, Eran. Having Wikidata values as placeholder make sense (along with Wikidata indicator to make sure they know). If the user fills in anything in the field, then that value should be used instead.

My biggest concern is is the architecture of the extension in light of the usage of this module.

The extension, by definition, goes to all Wikipedias, and needs to be generic, fast, and give as generalized solution to the general user as possible.
This is already hard because of the nature of templates on different wikis, but the current implementation does that exactly; it searches for local templates, loads their data, and allows the user to immediately post the template with or without information.

Adding an asynchronous behavior is something we should implement in a way where the architecture still allows for the above, as well as a way where wikis that don't use these relationships (and there are many) are not dependent on it. Further, this opens the door to potentially more services other users would want to query, like informaiton form Commons or any other API-driven data.

All that said, I think we should approach this slightly differently, and think about the Wikidata completion/hint as an asynchronous helper module. This one does Wikidata. A potential other can do preview of images, or structured data from commons when that's available, or any other asynchronous request.

I think it can be doable and not too insane if we go at it like that, and will solve a lot of the apprehension of going into this feature and thinking whether it's necessary. For some wikis it might be, and for others it might actually be disruptive, so doing this as a bit of a modular approach can save us a lot of headaches, bikeshedding and convincing one another that a module is needed for multiple wikis.

@eranroz how's this idea (off the top of my head, and we can hash it out more) :

• We add a special hook to TemplateWizard dialog just before initialization -- that hook can be used to add another action button for a module (say Wikidata, or whichever)
• We add another hook that fires just after the user (or the system) adds a field. This hook will include data about the template, the field, and the actual OOUI widget that the field is in -- This is where Wikidata module can fetch data and come back to set a placeholder or a value (or disable/readonly/etc) for the OOUI-field that was just added.

The Wikidata module can even cache values of those fields so that if a user adds and removes a field, the value that was already fetched will be reused.

I think this can be a great solution that wil allow us to add Wikidata in a modular way, AND open the door for other potential data-fetching stuff in the future. It can even be great for a potential on-wiki gadget to add its own behavior.

@eranroz @Samwilson what do you guys think? Am I missing a lot of complexity? Do you think it's a good path forward?

That sounds pretty good @Mooeypoo. For instance, I could imagine hooking in from a gadget on Commons to populate the {{inscription}} template with text retrieved from OCR.

Where do you imagine the Wikidata code would live?

I think keeping TemplateWizard itself wiki-agnostic is a good idea, but that we should add hooks wherever anyone wants them to make it easy to extend.

I think the 2nd hook would be the most useful, something like mediaWiki.hook( 'templatewizard.showfield' ).fire( { param: paramName, field: this.fields[ paramName ] } );?

@Mooeypoo I think this is good idea to have more generic architecture based on hooks.

In T199892#4467533, @Mooeypoo wrote:

• We add a special hook to TemplateWizard dialog just before initialization -- that hook can be used to add another action button for a module (say Wikidata, or whichever)
• We add another hook that fires just after the user (or the system) adds a field. This hook will include data about the template, the field, and the actual OOUI widget that the field is in -- This is where Wikidata module can fetch data and come back to set a placeholder or a value (or disable/readonly/etc) for the OOUI-field that was just added.

Sounds generic & flexible enough for most needs. (other possible hooks - on-done, e.g some communities may prefer different spacing around parameters and may want to control the output of the template insertion).

In T199892#4471162, @Samwilson wrote:

Where do you imagine the Wikidata code would live?

I imagine that code that is widely used in many wikis should live in extension for example:

• Commons - TemplateWizard extension
• Wikdiata - either in TemplateWizard extension or in Wikibase extension (Wikibase/client).

Other less widely used (e.g site specific) customization can be done using gadgets.