On 13 August 2014 20:08, Bene* <benestar.wikimedia(a)gmail.com> wrote:
As for mapping Wikipedia templates to wikidata
properties I think
James 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.
--
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester