Page MenuHomePhabricator

CX and VisualEditor template editors are not aware of parameters that can be auto-filled from Wikidata
Open, LowPublic


Some templates in some languages can auto-fill parameters from Wikidata. Examples:

In both cases, if the parameter is explicitly written in the template, it is used instead of the Wikidata value.

The problem is that if the translator is being made from a language where the template is not Wikidata-aware to a language where it is, the user doesn't know whether the parameter will be auto-fill the parameter. It was reported to me already by one Hebrew Wikipedia editor and one Catalan Wikipedia editor.

It would be very useful to see this information while translating. In most cases the translator can skip filling this parameter and save time. It will also affect other article maintainers, so they wouldn't have to remove unnecessary parameters that override Wikidata values.

This is relevant for VisualEditor as well: The VE template editor should say that a parameter will be auto-filled if the user doesn't provide a value.

I'm not sure whether it's technically possible to do it at the moment. Maybe TemplateData can have a parameter property that says something "auto-filled from Wikibase"? Just an idea.

Event Timeline

Maybe we could somehow add a markup on our homewikis to the templates that are importing content from Wikidata, so both VE & CX can "skip" this step.

  • VE On cawiki: if i do insert: template > infotaula de persona (infobox person) and click save, system works perfectly.
  • CX to cawiki: it would be lovely if system detects that a destination template can get content from Wikidata, taking it from there and skipping translation.

Thanks, @Kippelboy. The question is what this markup would be and how can it be used in all wikis and languages. As I noted in the initial description, maybe the definition of a parameter in TemplateData could include a property called "external" or "autofilled" or something like this (along with properties like "type", "required", "suggested", etc.). But I'm not a TemplateData expert and maybe there is a better solution.

I thought about this and I came up with the few possible TempldateData solutions:

  1. Wikidata map (see T69659 just appear above). and then we can handle it either in the frontend or backend:
    • Backend
      • Once we have such, we can add Hook in extensions/TemplateData/api/ApiTemplateData.php with CreateTemplateDataResponse - letting other extensions override the templatedata response.
      • In extensions/Wikibase/Wikibase.hooks.php handle it by iterating the map and generating ['default'] value for the TemplateData (e.g the default here is dynamic).
    • Frontend
      • VE should treat it in modules/ve-mw/ui/dialogs/ve.ui.MWTemplateDialog.js - this requires uglifiying the VE code (adding Wikidata specific binding code to more general code), and requires the client side to query the RepoApi for the actual values of the wikidata. I tried to create POC for it and realize this is probably bad idea...
      • Note: In the long term solution, we may want tight integration of WD in VE template allowing to edit WD - but this is not in the scope of this task but rather so I would rather avoid depending on it
  2. (ab)use default with values such as default: '{{#property:P123}}' for parameters. With or without parsing:
    • Without parsing - this is the current behaviour of TD and doesn't require any code changes. This may be somewhat meaningful even for pages not yet connected to wikidata (e.g "this parameter may be auto filled once connected to wikidata")
    • With parsing - Requires TD to call parser for default (and do it dynamically - not on TD save as it is page dependent). While requires the page to be already connected to wikidata, it is more meaningful (e.g show the actual data from wikidata rather then some wikisyntax for fetching wikidata). Note this requires also adding new page parameter to the TD api so it will know the context for parsing
Deskana moved this task from To Triage to Freezer on the VisualEditor board.