On 13 August 2014 20:08, Bene* benestar.wikimedia@gmail.com wrote:
As for mapping Wikipedia templates to wikidata properties I thinkJames F. mentioned something about including that into templatedata https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/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 https://dl.dropboxusercontent.com/u/17195534/Screen%20Shot%202014-08-13%20at%2019.29.49.png 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).
Ok, the transclusion with {{#property}} is one point which perhaps isn't too hard to solve. However, most of the infoboxes etc. will perhaps be created by a lua module and then it isn't trivial any more to find the place some specific information comes from. This is the point I think will make the thing tricky.
Sure, but an infobox is just a nested version of VisualEditor (or, will be soon), with each field being its own edit surface. Doing infoboxen with Lua is profoundly anti-wiki and hopefully won't be done.
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.
Yes, this is a problem and the reason why I suggested to make the edit interface as intuitive and simple as possible. Concerning the Wikidata policies, we may need some sort of global talk page where users can be notified from any place.
I believe that that's called Flow. :-)
However, the better way would be of course to not even let the users make mistakes by explaining the expected format well enough.
Yes, but asking the community to come up with clean, simple, concise (<10 words total or don't bother), jargon-free, easily-translated, up-to-date instructions "explaining" the format is asking a lot.
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! :-)
Indeed, although the language links are also a very different thing as they are not transcluded in the article at all and do not need Visual Editor for being edited.
Indeed, but when you're creating an article we would want to encourage users to link them to the right concept in Wikidata as part of their creation edit (timing with Wikidata's requirements that the target article exists will of course be a little challenging, but we can overcome them).
J.