[Interesting discussion! Have signed up.]

On 12 August 2014 23:08, David Cuenca <dacuetu@gmail.com> wrote:

On Tue, Aug 12, 2014 at 11:19 PM, Bene* <benestar.wikimedia@gmail.com> wrote:
Hello,

My Dream scenario is that the VE understands that the data is pulled from Wikidata and shows a dialog that is similar to the current template parameters. I see the old mayor's name in that dialog, I write the new mayor's name, and the new value is stored in Wikidata. Of course, it must be taken into account that the name is likely not just a string, but a label of the Wikidata item.

The problem I see here is that we mostly do not want to replace a value but rather add another preferred one and state that the old one is now deprecated. This means, we also want to have the old major on the Wikidata item but the new major should be marked as preferred. I think we have to think a lot how this can be implemented best in Visual Editor. Maybe we should just add the value entered there just as another preferred value but this is rather a guess because the data might also be simply wrong and should be replaced. We thus have to investigate how often the value should be replaced and how often the old value should be kept as well. Then we can decide a way how the visual editor should use this data without being to complicated but also offering all options to create the data as intended.


My acceptable-but-suboptimal scenario is taking the user to https://www.wikidata.org/wiki/Q6850543 . This is probably a useful workflow for the tech-savvy editors, but it's suboptimal for a casual editor. I'll go as far as saying that for a casual editor it may be (relatively) more comfortable to edit parameters in a MediaWiki template ("|mayor =[[Milan Ftáčnik]]") than to go to https://www.wikidata.org/wiki/Q6850543 and find the value.

We might take the user to the item's page on Wikidata if he wants to make more enhanced edits like replacing an old edit.


Does anybody have any more ideas about it?

For the technical implementation, we have to find a way which data comes from which item and which property. Maybe we can add some data-item and data-property attributes to the HTML tag in which the data is stored so that the visual editor can easy find these transclusions. However, this might also be a security issue if the attributes are added to elements not containing Wikidata data.

All in all, you are surely not late and this discussion has just started at Wikimania (although it is planned much longer to have something like that). Therefore, I think this feature hasn't hightes priority at the moment and needs lots of cooperation with the Visual Editor team. Perhaps we will start developing not before 2016. (Only my personal guess. :-)

@Bene*: The WE-Framework already has an interface for dealing with statement ranks, have you tried the latest version?

As for mapping Wikipedia templates to wikidata properties I think James F. mentioned something about including that into templatedata

​That's not quite right; I don't think TemplateData is necessarily the right avenue for Wikidata, though of course it might be possible to extend it for this case.

To VisualEditor, Wikidata properties​ are "just" another kind of transclusion, like templates, magic words, and parser functions. It's possible for VisualEditor to see an existing Wikidata reference as just another transclusion and not care where it comes from. For example, if you had the wikitext "{{#property:P646}}" (Freebase identifier) on enwiki's Foobar, you get something that sort-of looks reasonable but is not very user-friendly.

We haven't yet built in anything that lets you edit existing non-template transclusions very well[0], and we also don't support creating them yet (which is probably best done with a little pop-up listing all the available properties, their values and maybe description in the user's language). 

Longer-term I'd like to explore editing (rather than just re-using) values on Wikidata from straight within VisualEditor. However, I worry that that would need some exploration as to how we can avoid giving users a difficult set of explanations about differing community expectations of how they should work and what they should and should not do (quite apart from the different licence).

For example, a newbie-ish user of cswiktionary may not appreciate that Wikidata entries are not just magic but also done following some complicated conventions, and without a pan-wiki talk page they won't even notice that they've been bugged about making mistakes and violations until they eventually get blocked and complain that it stopped working.

Maybe the least-controversial thing to edit remotely would be language links, as they are heavily constrained and relatively simple, so maybe that would be the best place to start[2] (replacing the existing too in the sidebar).

Patches welcome! :-)


J.
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforrester@wikimedia.org | @jdforrester