Talk:Wikidata Bridge/2019

<figure-inline></figure-inline> This is the talk page about the Wikidata Bridge project. Feel free to give feedback or ask questions. Some threads are dedicated to specific questions or feedback loops.

<figure-inline></figure-inline> Dies ist die Diskussionsseite über das Wikidata Bridge-Projekt (Verknüpfung mit Wikidata). Gerne kannst Du ein Feedback geben oder Fragen stellen. Einige Themen sind bestimmten Fragen oder Feedback-Schleifen gewidmet.

Feedback on prototype v1.0

Here's the thread where you can leave feedback on the first version of the prototype.

Please note that it is a screenshot prototype, not a fully working feature: you will be guided to go from a screen to another and you won't be able to click on all links and buttons that you see on the screen. This is not the final state of the feature but a work in progress.

Do you see any problem with it? Do you have any concern to raise?

Are the texts helpful? (labels of fields, descriptions, information text)

Any other comment?

Thanks a lot! Lea Lacroix (WMDE) (talk) 09:38, 19 June 2019 (UTC)

Any other comment? On la.wikipedia, we predominantly use infoboxes that take all their content from wikidata. Since no user on la.wikipedia really knows Lua well enough to feel confident to maintain Lua code residing on la.wikipedia, we only use "normal" templates and the #statements parser function (and sometimes also the #property parser function) but do not use Lua. You can see an example infobox at la:Carolus de Gaulle.

From this perspective, I would like to emphasize two points:

• It would be great if the new system would not require Lua, as we feel we would not be able to reliably maintain Lua modules residing on la.wikipedia.
• On our infoboxes, we often see content displayed in English (serving as a fallback language), because many Wikidata labels have not yet been translated to Latin. Take for example the page la:Carolus de Gaulle and expand the "Officium" section. In the line starting with "Officium:", you will read: "president of the French Republic, President of the Council, president of the Provisional Government of the French Republic, Coprinceps Andorrae, Coprinceps Andorrae, praeses, Minister of National Defence". This comes from the P39 statements at d:Q2042. Note that "Coprinceps Andorrae" (d:Q683337) has both al Latin label and a Latin sitelink, "praeses" (d:Q1255921) has a Latin label but no Latin sitelink and "president of the French Republic" (d:Q191954) lacks a Latin label. It would be great if the new system you are planning to design and build would allow to translate such labels. UV (talk) 22:56, 24 June 2019 (UTC)

Hello, and thanks a lot for your feedback. We are aware that the lack of Lua skills among Wikipedia communities is an issue that prevents setting more efficient templates. One could think about various ways to solve it: provide better documentation in more languages, organize cross-communities trainings online or at events like Wikimania, provide global templates that everyone could use accross wikis, etc.

However, we think that this issue is independent and different from what we try to solve with the Wikidata Bridge. Lea Lacroix (WMDE) (talk) 07:51, 27 June 2019 (UTC)

Clarification: By "translate labels", I mean:

• add a Latin label if there is no Latin label, and
• change a Latin label (e. g. in case it is misspelt). UV (talk) 22:39, 25 June 2019 (UTC)

Hi, thanks to the development team for your work on this. I appreciate the tool although I worry a bit about the impact this could have on Wikidata (more vandals). We'll need a live feed of all Wikidata edits coming from eg. Czech Wikipedia so that we can keep track of it. Is this planned? Also, it would be cool if "transwiki" edits to Wikidata could only be enabled for experienced Wikidata users (eg. autoconfirmed on Wikidata). Vojtěch Dostál (talk) 14:02, 24 June 2019 (UTC)

Thanks for your feedback. We'll definitely discuss these topics on d:Wikidata:Wikidata Bridge.

As for the experienced Wikidata users requirement, we will need to find a proper solution, but the goal of the project is to help Wikipedians or newcomers who are not comfortable with editing Wikidata, to be able to do it, so it's targeting people who are not experienced yet. Lea Lacroix (WMDE) (talk) 15:30, 24 June 2019 (UTC)

Make no mistake, I am very open to newcomers and usually want Wikipedia as inviting to them as possible. I hate when all sorts of filters and roadblocks are put into place on Wikipedia. However, Wikidata are *more* difficult to understand than Wikipedia, one single edit can cause more disruption than on Wikipedia and thus Wikidata should be more careful about disruption from new editors than Wikipedia.

Let me give you a few examples of how Wikidata can be more challenging to understand. For example, in Wikidata, we differentiate between a museum building and a museum. That's something usually unseen in Wikipedia. which mixes up both concepts (which is all right for Wikipedia but wrong in Wikidata). Another example: in Wikidata you would not remove a 2018 number from population census once a 2019 figure is published (as you would do in Wikipedia) - rather, you would add a new value next to the existing one and add a proper qualifier "year". Vojtěch Dostál (talk) 15:37, 24 June 2019 (UTC)

I understand your point. The first version will also be the occasion to monitor the edits and evaluate their quality (eg how many of them have been reverted). Based on this data, we can think about improving the interface on Wikipedia, or provide better watching tools on Wikidata. Restricting the possibility to edit to a certain group of users is an option that we could consider as a last step if really needed. Lea Lacroix (WMDE) (talk) 07:54, 27 June 2019 (UTC)

When listening to Mr Denny Vrandečić I get the feeling the biggest benefits he sees of the Wiki echo system is that you have many "eyes" checking the data. I would like to see some thoughts of how a good wikiecho system works and how this piece fits in. Some examples of confused thoughts

• all edits in one Wiki infobox should be seen directly on all other language versions
• when Wikidata is changed the change is indicated in an Infobox that a diff exist
  • if there is a change it needs to be approved
  • if a change is approved in x Wikis its accepted as trusted and shown in more Infoboxes
• a change need to have a reference/source or get a higher "trust" value if it has
  • a change need to have a source that is on a trusted list of sources
• we have in Sweden done WD objects for all Swedish Church parishes GITHUB that means we try to follow a structure that a person is born or dead in one of those parishes i.e. very few other languages has labels for those items
  • any strategy to use labels when new changes will appear in more infoboxes and we have no labels
    • the change stream should indicate that we now have a new WD object appearing in your language wiki that has no label in your language
• .....

Salgo60 (talk) 16:20, 24 June 2019 (UTC)

Thanks for your feedback and suggestions. Let me answer on a few points:

• The ability to watch Wikidata edits from Wikipedia already exists. If an article uses an item, then it's possible to watch the changes made on this item on one's Wikipedia watchlist.
• Approving edits a posteriori is not what we want as Wikidata is an open project. We can consider this; after deploying the first version, analyzing the usage and the quality of edits, and asking feedback from the community: if we get a strong request from the community, we could consider it for next version in the future.
• Yes, references will be part of the interface (maybe not on the first version)
• About monitoring: items without labels: it is already possible to do this by adding some extra code the template that would add maintenance categories Lea Lacroix (WMDE) (talk) 07:59, 27 June 2019 (UTC)

Here are few suggestions/feature requests:

1. Field validation on Coordinates, Altitude, Units, Data types, future field value etc. need to be take care.

2. WhatIf I have to add a new InfoBox field, which is not there? i.e. can a User/an Admin change the template of the Infobox?

3. More than 50% unique users visiting Odia Wikipedia use Smartphone. Is there any plan to bring this feature to Mobile web/Android App?

4. I see some fields are not editable. Is there any specific reasons? or How is it decided?

5. Search and upload Image feature from the Infobox directly. Soumendrak (talk) 17:16, 24 June 2019 (UTC)

Thanks a lot for your suggestions!

1. Absolutely, it will come later in the next versions

2. The template builders will be able to add new infobox fields by changing the template

3. Yes, it is planned that the feature will work on mobile web interface. As for the app, we can't promise anything, since it's a different organization taking care of it (Reading team at WMF)

4. I'm not sure that I understand what you mean. Did this happen while testing the prototype? If so, that's normal: the prototype is no fully-functioning software but only a step-by-step tool that is leading you through one only path (editing the altitude)

5. This seems way bigger than the Wikidata Bridge. It could be develop in a near to distant future. Lea Lacroix (WMDE) (talk) 08:02, 27 June 2019 (UTC)

Do you see any problem with it? No. This is really promising.

Do you have any concern to raise? No.

Are the texts helpful? Are we talking about the info labels in the infobox? They are indeed helpful. Maybe I don't understand this question. Were there talk before about removing the labels in infoboxes?

Any other comment? Thank you for your work! Reem Al-Kashif (talk) 17:44, 24 June 2019 (UTC)

Do you see any problem with it? The main flow looks right, but several details are unclear as described below.

Are the texts helpful? Why lowercase "edit" in the title? Not sure about the "Apply changes" label either - this is supposed to appear in the Wikipedia context, so it might be better to use "Publish changes", like the Wikipedia editors

Any other comment? Please make sure that the wrong/outdated strings are as flexible as possible: gender/plural/placement customizations should be possible, e.g. in Romanian you would say "altitudine greșită" (feminine), "coordonate greșite" (plural), but also "cod greșit" (masculine singular) - in all cases the qualifier comes after the label

Also, what's the workflow for multiple values (e.g. villages in a municipality) and images? What about qualifiers and sources? Strainu (talk) 21:15, 24 June 2019 (UTC)

Thanks a lot for your feedback! We'll take in account your comments about labels and customization.

Multiple values and qualifiers will not be part of the first version, as they are connected to various complex use cases that we need time to study. But they will be worked on in the future versions. Sources will be part of the interface as soon as possible. Lea Lacroix (WMDE) (talk) 08:04, 27 June 2019 (UTC)

I have been looking forward to it for several years and I say quite often that it will be online soon! :)

I haven't found any information about how the new system will be implemented on existing infoboxes. Will it be a special templates? By plug-ins? By Lua? Will How difficult will it be?

Or will there be a new infobox system? (no templates, standardized, easy setup eg. P131 to this line in cs lang and with/without ref) That would be best. Frettie (talk) 22:06, 24 June 2019 (UTC)

Thanks for your feedback!

There will be no new system, the interface will be based on existing templates, so the communities don't have to perform a big change, but rather update their templates step by step when they feel like it. We are still investigating on the best technical solution for these improved templates. Lea Lacroix (WMDE) (talk) 08:06, 27 June 2019 (UTC)

Suggestions:

• Edit icons/buttons could be easier to select and look less busy if provided in a 3rd column in Infobox tables, making the columns correspond to: field_name, field_value, edit_button.
• Edit dialog should ask for a reference to be provided for any new value provided.
• "Wrong Value" should ideally be split into "Wrong Value - Vandalism or No Reference" (removes the Wikidata value) and "Wrong Value - Published Error" (deprecates the Wikidata value). If this split can't be done, the Wikidata value should be deprecated instead of replaced/removed, allowing someone using the Wikidata interface to decide why the value is wrong. Dhx1 (talk) 05:04, 25 June 2019 (UTC)

Thanks a lot for your valuable input!

• About edit icons: thanks for the suggestion, we'll have a look at it.
• We're currently figuring out how to best work with references. Thanks for the idea.
• We're looking into ways to make the template as smart as possible, without asking the editor too many questions that could lead them to abandon the edit. We'll not deal with deprecated rank in the first version but could consider it in the future. Lea Lacroix (WMDE) (talk) 08:10, 27 June 2019 (UTC)

I really agree with the need of providing references. Paucabot (talk) 05:10, 25 June 2019 (UTC)

Additional suggestions:

• Require the user to enter values for any qualifier properties listed by P2302 (property constraint) Q21510856 (mandatory qualifier constraint).
• Ask the user to enter values for any qualifier properties listed by P2302 (property constraint) Q21510851 (allowed qualifiers constraint). Dhx1 (talk) 05:24, 25 June 2019 (UTC)

Thanks. Suggesting and checking values will not be part of the first version, but we'll definitely look at it later. Lea Lacroix (WMDE) (talk) 08:11, 27 June 2019 (UTC)

@Lea Lacroix (WMDE): perhaps the first version should check that the Infobox property does not have P2302 (property constraint) Q21510856 (mandatory qualifier constraint). If there is at least one mandatory qualifier then the edit icon would be hidden and editing from Wikipedia disallowed. For example, P1279 (inflation rate) doesn't make sense as a standalone statement--it requires P585 (point in time) to specify the date upon which the statement is valid. Dhx1 (talk) 13:59, 27 June 2019 (UTC)

Hi all,

I was looking at the prototype and it totally confused me:

1. http s://www.figma.com/proto/KIkcQ7NjOl8OkQtGWe5duIbW/Client-editing-UI?node-id=281%3A2956&scaling=min-zoom&redirected=1 found on Talk:Wikidata Bridge/2019#h-Feedback_on_prototype_v1.0-2019-06-19T09:38:00.000Z links to page 8 instead of 1
2. it is still a mockup, right?

What is the scope of this? It can only edit infoboxes that use Wikidata already? or more?

How is it realised? Will it be included in the Visual Editor or a gadget?

I am asking, because we will finish the first backend services for https://meta.wikimedia.org/wiki/Grants:Project/DBpedia/GlobalFactSyncRE and it might be helpful to include here.

We will post all references extracted from Wikipedia for example SebastianHellmann (talk) 07:22, 25 June 2019 (UTC)

The current policy on the big Wikipedia's regarding Wikidata is that only statements with sources can be displayed on Wikipedia. Given that the prototype involves users entering unsourced statements, the prototype doesn't seem to provide the necessary functionality to be used on the big Wikipedia's.

Even from the Wikidata side, we don't want people to remove existing data and replace it with new data without providing a source that backs up the new data in cases where the old data is sourced.

While we might allow unsourced statements in some cases to be entered from Wikipedia, design prototypes should include a way for the user to specify the source for the information they enter as that's one of hard things to get right. ChristianKl (talk) 10:02, 25 June 2019 (UTC)

Thanks for your feedback. We're aware that references are an important part of data quality and acceptation of Wikidata's data by the Wikipedia communities, and we'll look at how to include references in the Wikidata Bridge interface as soon as possible. Lea Lacroix (WMDE) (talk) 08:13, 27 June 2019 (UTC)

The current policy on the big Wikipedia's regarding Wikidata is that only statements with sources can be displayed on Wikipedia. Given that the prototype involves users entering unsourced statements, the prototype doesn't seem to provide the necessary functionality to be used on the big Wikipedia's.

Which Wikipedia are you referring to ? This is not true for example in frwiki. TomT0m (talk) 12:21, 25 June 2019 (UTC)

I'm primarily reacting to the discussions on enwiki. There people complain about unsourced Wikidata statements and are generally opposed to unsourced Wikidata statements being imported into enwiki. The sense I got on dewiki was generally similar.

But even if it wouldn't be a requirement from the side of Wikipedia, it's still important for us. Unsourced statements shouldn't be able to overwrite sourced statements. You could solve that by not showing the user the option to edit the value in the template, but that would make it confusing for users to know why they can't edit a specific claim and some of those users would likely complain and don't get a good impression about Wikidata out of the process. ChristianKl (talk) 14:06, 25 June 2019 (UTC)

Well, digging into the first Lea’s link a little bit we jump to this image which seems to take this problem into account. TomT0m (talk) 14:52, 25 June 2019 (UTC)

I don't think it does. Clicking neither of those options should do something when the user doesn't provide a source for the new value. To me that image just feels like it wants to set the ranks of statements.

As far as enwiki discussions go there's the RFC from 2018 and in it's summary it has:

Despite this clear bifurcation, there is a consensus on one point: if Wikipedia wants to use data from Wikidata, there needs to be clear assurances on the reliability of this data. Of the many options, 3A, "Each statement imported from Wikidata must comply with Wikipedia policies", was the only option in the entire matrix in the poll to gain a majority: 52% percent of those expressing a preference in question 3 supported this option. If we define this to mean that the data drawn from Wikidata must be what is generally considered "reliable", then when we combine the share of votes from two other related options, 3C ("Require source") & 3D ("BLPs sourced"), this results in 78% of participants in the poll expressing some form of assurance about the reliability of the material drawn from Wikidata.

The only way we can provide that demanded assurance is by not giving Wikipedia unsourced data. If we try to deploy a tool on enwiki that is about unsourced Wikidata statements that sounds to me like asking for trouble and for someone to start the next anti-Wikidata RFC. ChristianKl (talk) 07:35, 26 June 2019 (UTC)

I mean this answers to the « overwrite » point at least. It seems obvious that by the answer of this question will trigger the creation of a new statement and the change of rank of the other one. This means this is not really related to the « make source mandatory » question. (although this poses the question of if this fits all the legitimate and in use usage of ranks we can observe on Wikidata and the consumers) TomT0m (talk) 07:45, 26 June 2019 (UTC)

The current policy on the big Wikipedia's regarding Wikidata is that only statements with sources can be displayed on Wikipedia. Given that the prototype involves users entering unsourced statements, the prototype doesn't seem to provide the necessary functionality to be used on the big Wikipedia's.

Not true for Swedish Wikipedia

• we dont show Wikipedia references...
• we show max 3 referencies (the first 3)
  • we have no ranking of sources to be shown (which I feel we need) Salgo60 (talk) 12:23, 25 June 2019 (UTC)

Hi! Please remind the new editor that he is going to modify a statement with references. Something like: You are going to change a statement backed by 3 references [to be shown in the box] by a statement with no references. Are you sure about that? Or allow only changes for statements without references [excluding Wikipedia references] to be changed through that way. On Arabic Wikipedia, we usually put a one line template code to avoid having edits by new editors in the wikidata-based infobox. See California article as an example. Helmoony (talk) 16:07, 25 June 2019 (UTC)

Thanks for the idea. We'll definitely look at it for further versions. Lea Lacroix (WMDE) (talk) 08:15, 27 June 2019 (UTC)

One thing that the Wikipedia community reacts on is if a Wikidata driven Infobox presents occupations in the "wrong order" and the order is normally not logical is my feeling its more a subjective feeling that this occupation should be first in the list as I think its important.....

Suggestion is to have a drag/drop interface to change position in the list....

At Wikidataconf 2017 I spoke with the people from Histropedia that we should have some kind of small icon/or mini timeline that you could expand which I feel is a better way of use WIkidata and display events in a persons life

• example Leonard da Vinci SPARQL timeline Salgo60 (talk) 11:33, 26 June 2019 (UTC)

@Salgo60: the order would have to be stored somewhere--probably a new qualifying Wikidata property a bit like P1545 (series ordinal) but named along the lines of "display order ordinal" without needing references and being subjective. I'm not sure that kind of vagueness/objectiveness would be welcomed on Wikidata though. Dhx1 (talk) 12:20, 27 June 2019 (UTC)

This would be an extremely nice thing to have! One suggestion to the team: don’t make the tool too complicated, make it generic (but still useful) and make it work great. The problem with WE-Framework, for example, is that it is so specific that it stops from being useful. Current prototype is kind of the same in the other way: you can’t alter the units as proposed, there’s no way for person to back up their claims with references.

P. S. Small windows can be bad for multilingual text, as can be seen in T151313. stjn^[ru] 19:02, 27 June 2019 (UTC)

Template Graph

Hello

is this project impacting the Template:Graph:Lines being unable to show wikidata queries result (since few weeks), only raw data ?

https://phabricator.wikimedia.org/T226250 Bouzinac (talk) 14:43, 24 June 2019 (UTC)

Hello,

I'm pretty sure that the issue and the Wikidata Bridge are unrelated, since no development was deployed so far. Lea Lacroix (WMDE) (talk) 15:27, 24 June 2019 (UTC)

References

Hello, I think that it's important to focus on verified information for each statement that are added. There should be an option for adding sources (d:Help:Sources). Maybe using something like citoid, to make it more user-friendly. This is important for both projects, so it should be implemented in the prototype v1.0. Premeditated (talk) 16:01, 24 June 2019 (UTC)

Don't forget the excellent WEF framework which zooms in a certain property, helps sort it (helpful when many data) and edit with a source Bouzinac (talk) 18:21, 24 June 2019 (UTC)

Hello,

Thanks for your input. Indeed, we're aware that references are very important and we'll try to have them, at least in a simple version, in the first version of Wikidata Bridge.

We're well aware of WEF, we've been observing what various communities are doing and discussing with their template editors :) Lea Lacroix (WMDE) (talk) 08:19, 27 June 2019 (UTC)

A similar project

I made some attempts on something pretty similar some years ago, but put the editing interface into a bubble. At the same time the pencil icons were added to the infoboxes, they linked to the property hash mark, and having two interfaces created confusion. Pretty soon it became pretty obvious that the pencil solution had some serious issues when a row in the infobox used two or more statement and especially when those two statements used different properties.

I tried out a couple of access methods. One added a tool link to the left of the row on hover. That worked quite well, but failed on being clear on the confusing two-statement problem. An example of the problem is a single infobox row with both a birth data and a birth place. I made a popup menu on the row itself, having two entries, but even when that worked the two-level menu-like behavior was somewhat cumbersome.

The solution is quite obvious. Editing a row that uses two statements are really about editing two statements (That is a bomb-shell!) and only editing one is enforcing the wrong process. Click on the row and open both statements in one and the same bubble.

The way identified the properties for editing was by adding them as classes, but a better way is probably to use data attributes. Jeblad (talk) 16:03, 24 June 2019 (UTC)

Also, I believe the popup should be able to edit both the local value and the value at the repository, and if you chose to put the value at the repository then the local value should be reformatted accordingly. If the local value can't be reformatted, then the user should be notified.

Note also that the local value can contain a reference, which should be reformatted and go into the references (sources) section.

Reformatting qualifiers is a non-trivial problem. Jeblad (talk) 19:34, 24 June 2019 (UTC)

Thanks a lot for your feedback and your ideas.

Yes, the ultimate goal would be to have an interface that can edit both local and Wikidata value, or allow to switch from one to another. This will not be part of the first version because we still need to think about technical solutions to perform these actions, but we're definitely keeping it in mind. Lea Lacroix (WMDE) (talk) 08:18, 27 June 2019 (UTC)

Prototype and scope

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi all,

I was looking at the prototype and it totally confused me:

1. http s://www.figma.com/proto/KIkcQ7NjOl8OkQtGWe5duIbW/Client-editing-UI?node-id=281%3A2956&scaling=min-zoom&redirected=1 found on Talk:Wikidata Bridge/2019#h-Feedback_on_prototype_v1.0-2019-06-19T09:38:00.000Z links to page 8 instead of 1
2. it is still a mockup, right?

What is the scope of this? It can only edit infoboxes that use Wikidata already? or more?

How is it realised? will it be included in the Visual Editor?

I am asking, because we will finish the first backend services for https://meta.wikimedia.org/wiki/Grants:Project/DBpedia/GlobalFactSyncRE and it might be helpful to include here. SebastianHellmann (talk) 07:18, 25 June 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Beta-testing on ro.wp

In the Romanian Wikipedia we already make heavy use of Wikidata in our infoboxes. We would like to participate in the beta testing session of this feature when the time will come. Andrei Stroe (talk) 12:35, 27 June 2019 (UTC)

Hello, and thanks a lot for your suggestion! Is there already a discussion within the community? We don't ask for a proper consensus but at least that the people who maintain infoboxes are aware and enthusiastic about it :) Lea Lacroix (WMDE) (talk) 14:31, 28 June 2019 (UTC)

The response to your announcement is that discussion. It's brief for now, as there aren't many of us who maintain infoboxes, but I'll ask again for an explicit agreement. Andrei Stroe (talk) 14:34, 28 June 2019 (UTC)

Awesome, thanks! I'll keep your contact and let you know as soon as I have a clearer view of the next steps and how your community can get involved :)

Do you have a link to an example of an infobox that reuses Wikidata's data? Lea Lacroix (WMDE) (talk) 14:36, 28 June 2019 (UTC)

There are several examples. w:ro:Modul:InfoboxSettlement (see w:ro:Novi Pazar, Serbia for a page where it takes all information from Wikidata) and w:ro:Modul:InfoboxTeamSportBio (supporting w:ro:Format:Infocaseta Fotbalist and w:ro:Format:Infocaseta Handbalist - see w:ro:Ianis Hagi for a use example) are infoboxes written in Lua to obtain data from Wikidata. Others just rely on a generic infobox template and take advantage of some other useful templates dedicated to pulling data from Wikidata. One of these is w:ro:Infocaseta Galaxie, se as an example w:ro:NGC 1097. Andrei Stroe (talk) 15:12, 28 June 2019 (UTC)

Betatesting at nowiki

Seems like nowiki has passed critical mass of users voting “for” in our poll for consensus. The poll is still on-going, but I doubt the outcome will be much different. The group of usual no-sayers at nowiki is to small to change the outcome substantially. The poll is finished 14:41 (UTC) 1. July 2019.

At nowiki we have various solutions to the edit infobox problem, but among the more common ones is a link with a pencil symbol to the correct section in the Wikidata item. I guess it should be pretty easy to tweak. Jeblad (talk) 13:13, 27 June 2019 (UTC)

Thanks! Can you give a link to the poll? Lea Lacroix (WMDE) (talk) 14:29, 28 June 2019 (UTC)

Sorry, forgot! My bad. The poll is at w:no:Wikipedia:Tinget#Rediger Wikidata rett fra infoboksen. I'll add a permalink/archivelink when it is closed. Jeblad (talk) 14:47, 28 June 2019 (UTC)

Final outcome is 18 for joining the betatest, and none against. [1] [Later increased to 20 for and none against.] Jeblad (talk) 15:52, 1 July 2019 (UTC)

Added a notice at Tinget (w:no:Wikipedia:Tinget#Rediger Wikidata rett fra infoboksen (2)) because of the discussion about references, so the community can decide whether to go forward or not with the betatesting. I doubt it will be any change, this is just to make sure everyone knows about the implications. Jeblad (talk) 16:28, 6 August 2019 (UTC)

Thanks! We're currently working on a way to view and edit references, so it can be part of the first testable version. Lea Lacroix (WMDE) (talk) 06:39, 7 August 2019 (UTC)

Seems like later polls have made the current consensus quite muddy, and I don't believe it would be wise to do betatesting at nowiki. Some users seem to have misunderstood what Wikidata Bridge is all about and any clarifications are reputed. Some users even openly refuse to cooperate at all. It is a bit weird.

A few modules and templates are prepared for use of WB, but I removed and/or turned off the actual code. Should be pretty easy to turn back on though.

In short, drop betatesting at nowiki. Jeblad (talk) 12:39, 12 July 2020 (UTC)

Hello Jeblad,

Thanks for letting us know. There's no problem from our side. We understand that communities need time and it may be a bit too early at that stage. We will keep experimenting with other wikis who are ready to test the early phases of the Bridge, and hopefully in the future, when the feature is more advanced and people can see the benefit of it more clearly, we can start a discussion on nowiki again.

Thanks for your communication efforts! Lea Lacroix (WMDE) (talk) 07:53, 13 July 2020 (UTC)

Some questions about the software

I only found out about this today, so I may have missed something. I have tried to use the demo, or at least I think I clicked through to it.

Anyway, I do have some questions and concerns. (These may be relevant to both the minimum viable product and future versions of the software.)

1. When will the software overwrite existing values – always, sometimes or never? (The reason I ask, for those who are unaware, is that it's actually quite rare for it to be good practice to delete a previously valid value. Often either the new value should be marked as preferred (e.g. things that normally change over time) or the old value should be marked as deprecated (e.g. things that are newly discovered to be incorrect). In some cases none of the values should be preferred or deprecated (e.g. child (P40)), and in some cases multiple values may be preferred (e.g. occupation (P106)).)
2. Will there be per-property or per-template options on Wikidata to specify what should happen when a value is modified, or will this be left to template creators? Allowing this to be set for each property would presumably save time and prevent stuff from breaking. (I think this might actually be possible with a Wikidata property to be used on other Wikidata properties, but that route wouldn't work for infoboxes that use the plain parser functions, as you would need a helper Lua module to bring the values to the templates.)
3. Will the software surface the options to change preferred and deprecated ranks?
4. If there are things that won't be editable through this interface, will the software assist the user in finding help or in modifying the item through the actual Wikidata interface?
5. How will the software handle properties for which multiple values are used (e.g. occupation) and for which all (or some) of the values should be shown in an infobox?
6. How will the software handle statements with qualifiers and references? If a value is overwritten, will the qualifiers and references stay? (Obligatory note that qualifiers can significantly change the meaning of a statement, especially for properties for which qualifiers are mandatory.)
7. How will the software handle properties for which multiple statements with the same value but different qualifiers may be used (e.g. political offices held more than once, both non-consecutively and consecutively)? (I ask mainly because QuickStatements cannot add or modify such statements correctly.)
8. On Wikidata, statements with an obvious sorting order are usually left out of order because it doesn't matter. If these are presented as sorted by the template (e.g. if Lua is used to sort the values), will the software be able to handle this properly or tell users not to break the existing values?
9. Some Wikidata templates/modules can take the first value for a property (regardless of whether any values are preferred or deprecated) and discard the others. (I have recently used this configuration in several external link templates.) Will Wikidata Bridge be able to handle this? Will it be able to tell the user about the other values, if there are any?
10. Will the software tell users how to add local parameters (e.g. fair use images) or allow users to do it through the interface?
11. How will the software handle wikilinks? Assuming that the user is supposed to enter a page name and not a QID, if a user enters the title of a redirect that is linked to a Wikidata item, how will the software react? Will it ask the user to differentiate between the redirect's item and the target's item?
12. How will the software handle units? As an example, on the English Wikipedia, both kilometres and miles may be acceptable for the same field, so it could be necessary to allow this to be modifiable (I would note that the demo/prototype actually omits the unit, which could be detrimental).
13. Which datatypes will the software be able to support upon initial wide release? Is the goal to support every datatype, or just a subset of them?

As an editor of both Wikipedia and Wikidata, I'm cautiously supportive of this, but there are a lot of edge cases that would have to be handled before allowing random users to set this up everywhere, since you could break a lot of items by making it easy to enter bad data that looks correct into an infobox. It would be a shame if this just ends up making it more difficult for Wikidata editors to keep items in order. Jc86035 (talk) 06:44, 2 July 2019 (UTC)

Thanks for your feedback! Here are the answers from the development team.

1. The interface will guide the editor through edit flows to make sure that the right action is made on Wikidata. Overwriting existing values can happen from time to time, when the existing value is wrong and needs to be fixed.
2. It's going to be a per template options, that can be set in Lua, because of some very generic properties that are use in various places
3. Ideally, the tool will edit ranks, but in way that is transparent for the Wikipedia editors? Our goal is to allow Wikipedia editors to edit Wikidata's data without having to fully understand the data model.
4. Yes, that's a good point, we'll have a link or icon "edit on Wikidata" somewhere
5. We'll try to show them all in the interface (that will probably not happen in the first version, but later)
6. We are not sure how it will work, we're still looking into this
7. Hopefully this will be solved by showing all values (see 5.)
8. I'm not sure how this would be a problem - can you describe a use case where the order could induce a mistake from the user?
9. Yes, by showing all values
10. Not in the first versions, possibly later
11. In the first version, the tool won't be able to edit values that are links to items - so the question will be solved later
12. Good point, the editor should be able to see and change the unit
13. In the first version, we won't support values that are links to other entities (items, properties, etc.) We'll definitely support string and URL datatypes. We'll try to get as much as we can for everything in between. Lea Lacroix (WMDE) (talk) 08:28, 2 July 2019 (UTC)

As an aside to #12, right now each property has to specify its own valid units in its constraints. It would be really nice if these (and similar types of needlessly-duplicated constraints) could be unified across properties which are supposed to use the same units, particularly because a different structure could potentially allow for customizations within Wikidata Bridge like putting important units first and hiding joke units like smoot (Q2095762) and fortnight (Q2993680) or very specific units like Stardate unit (Q50277568).

This sort of work could also potentially be used to improve the actual Wikidata/Wikibase interface – I think a static dropdown would be a welcome improvement over the current find-the-item-yourself search box. Jc86035 (talk) 09:35, 2 July 2019 (UTC)

For #8: there's a small chance that the values being shown out of order could nudge a good-faith user to "sort" the values by deleting all of the ones that are out of order, and that could result in errors being introduced (particularly if some parts of the data aren't shown). Jc86035 (talk) 08:31, 2 July 2019 (UTC)

For #1: I think it's considered good practice to leave in certain deprecated values (e.g. see d:Q167#P1181), so perhaps it could be left up to other Wikidata editors to remove the deprecated values. Jc86035 (talk) 08:36, 2 July 2019 (UTC)

For #2: How will this be "set in Lua"? Will the dialog boxes be enabled by using e.g. HTML attributes to activate JS (which would not require Lua), or will the module have to generate the dialog boxes? Is there a particular Lua function which will be necessary for this? Jc86035 (talk) 08:41, 2 July 2019 (UTC)

I also have another question (thank you for your quick response, by the way). Some templates, such as w:en:Template:Authority control, have one pencil icon for all of the data. Will the template have to be changed so that each identifier has to have its own pencil? Jc86035 (talk) 08:44, 2 July 2019 (UTC)

Yes, this is probably part of the small changes that the template maintainers will have do to, in order to have a Wikidata Bridge-compliant template. Lea Lacroix (WMDE) (talk) 09:21, 2 July 2019 (UTC)

EnWiki reception of Wikidata

I see your UX Research page already has a link to EnWiki 2018 Infobox RfC. However I don't think you fully appreciate what that RFC says and what it means.

A very oversimplified summary would be that about half the community support Wikidata in infoboxes, and about half the community oppose use of Wikidata.

A somewhat more nuanced explanation would be that 1/3 of the community support Wikidata in infoboxes, 1/3 want it GONE, and 1/3 find the current usage of Wikidata problematical but they would be willing to support Wikidata in infoboxes if their concerns can be met. Some people would argue that it is impossible for Wikidata to meet those conditions. It could be argued that the 1/3 in the middle haven't followed the issue closely enough yet, and that they haven't yet figured out that Wikidata can't satisfy those requirements.

There have been a number of other Wikidata-related RFCs since then, denying or removing Wikidata from other locations.

• There is a substantial likelihood that your project will provoke a new Wikidata RFC on EnWiki.
• There is a very real possibility that your project will effectively trigger a ban of Wikidata on EnWiki. I would hesitate to claim any particular percentage chance on that outcome. The issue is precariously undecided among the community, and my impression is that it may be tilting against Wikidata.

I anticipate little chance this post is going to affect the course of your project. However I did want to alert you of the situation and the potential effect.

And as someone else noted, this tool would be literally unusable for unsourced items on EnWiki. There is an overwhelming rejection of unsourced items. The range of debate on EnWiki is whether sourced items are permissible. Alsee (talk) 09:31, 5 July 2019 (UTC)

This tool's purpose is to edit Wikidata. Infoboxes could still use values set locally (in the ways as usual) and I think this tool could work on infoboxes and their properties without enabling to show in them values from Wikidata. wargo (talk) 15:30, 7 July 2019 (UTC)

Was it really necessary to immediately assume that the team had no idea what was said in the 2018 RfC? Many of the WMDE staff have worked on Wikidata for nearly six years, so I doubt that they would be unaware of Wikidata's reception on the English Wikipedia.

I doubt that this will result in an outright ban on Wikidata transclusion. Although most properties are rarely used in English Wikipedia articles, consider the authority control template – it would take almost a million edits for the Wikidata values to be replaced, and it would be needlessly difficult (if not completely pointless) to replicate Wikidata's semi-automatic identifier matching tools. (Right now, 60.6% of English Wikipedia articles use at least some Wikidata data; this is the 44th-highest percentage out of all Wikipedia editions' usage percentages.) Even if you assume that Wikidata data will never be usable on the English Wikipedia, I think it would probably require a significant amount of work to completely remove all Wikidata data at this point, and it could be potentially difficult to find consensus for this.

Another RfC could be a useful opportunity; a possible outcome could be to hide the pencil icons for (e.g.) unregistered users by using CSS classes. And by that time, I think Wikidata's ratio of sourced to unsourced statements would have improved since 2018, especially considering the DBpedia data-sync project and the other ongoing initiatives.

Furthermore, the WikidataIB module can ignore Wikidata values if they aren't sourced properly (and the pencil icon can also be trivially enabled or disabled, since it's just an image with a link), so I'm not sure why it's necessary to focus on unsourced data so much. Given that the draft technical documentation shows that the Wikidata-editing pop-up will be enabled through the addition of a single HTML attribute to a wrapper around the pencil icon, this would only be an issue where some values for a particular property on an item are sourced and some of them aren't (all the values would be shown in the pop-up).

In any case, it doesn't necessarily even matter if it's not going to be usable on the English Wikipedia for some years. The English Wikipedia is not the only wiki that matters, and the software will still be ready for whenever Wikidata gets those mass imports of sources. Jc86035 (talk) 06:10, 8 July 2019 (UTC)

I'm not sure why it's necessary to focus on unsourced data so much.

It was barely mentioned. And it was mentioned because the documentation says they are building something with no support for sources at all. That means it won't even function on EnWiki unless/until they do add support for sourcing.

Devs: I just realized something. When you say your building something with no support for sources, does that mean the software will update the value and:

1. Delete any source information that was attached? Or...
2. Not-touch any preexisting source that was attached?

Neither option is particularly good, but I really hope you already considered this issue and already realized why one of those options would be extremely bad. Angry mob bad.

Another RfC could be a useful opportunity; a possible outcome could be to hide the pencil icons for (e.g.) unregistered users by using CSS classes.

No, that's not credibly possible as an outcome. The debate was whether to use Wikidata in infoboxes at all, and there were a lot of complaints that the RFC was overly complicated. We're not going to include trivial details like the pencil icon in the same RFC debating whether to fully deploy or fully rollback use of Wikidata in infoboxes. Small details like the icon would have to be addressed separately. The icon is irrelevant if the community decides Wikidata doesn't belong in infoboxes at all.

I expect the next RFC will follow up directly from the result of the last RFC. The result was that Wikidata might be acceptable for use if the relevant concerns are satisfied. I expect the RFC will ask whether Wikidata content is a sufficiently reliable source in specific and sufficiently compliant with Wikipedia policies&guidelines in general for automated import of Wikidata content into Wikipedia.

Wikidata's ratio of sourced to unsourced statements would have improved since 2018

The ratio of unsourced statement is irrelevant because the unsourced statements are irrelevant. They are already blocked. The only problem is the sourced statements.

WikidataIB module can ignore Wikidata values if they aren't sourced properly

No it can't. I discussed this with the module developer. The module makes an simplistic attempt, and it does filter (most) unsourced items. However it can't even reliably filter out items circularly sourced to Wikipedia. (It pattern-matches for "Wikipedia" in the source field, but millions of items are sourced to Wikipedia without having that text string anywhere in the source field.) The WikidataIB maintainer also refused to even attempt to filter out items which are circularly sourced to Wikidata. (Those items may be unsourced, but pass through the filter because there is a circular source claim attached.) The filter can't reasonably detect which items are circularly sourced to Wikidata, any such filter would have to overblock a massive percentage of all sourced items on Wikidata. And that's not even considering the universe of general bad sources, and other issues. Alsee (talk) 09:43, 9 July 2019 (UTC)

I have some problem with your affirmation "No it can't." It is possible to filter values to avoid values with no source or sourced by a wikimedia project (using property P143 "imported from Wikimedia project"). I know it because the French WP has developped the lua module for that (see https://fr.wikipedia.org/wiki/Module:Wikidata, parameters withsource and sourceproperty).

Then there are still some wrong formatted references using P248 "stated by" linked to a wikimedia project. But this can be handled by curating the data in WD with a bot.

Now if you want to filter value according to a reduced number of references you considered as reliable, this can be done: you just need to create a filter which analyzes the references linked to a value and match the references you listed.

Finally I don't understand your affirmation "WikidataIB maintainer also refused to even attempt to filter out items which are circularly sourced to Wikidata." As references as defined in particular item, any reference link will point to a WD item. You should explain what is you problem with circularly sourced to Wikidata.

The main solution for your problem is on WP side by developing the filter which will extract the data you want: WD has a model for reference (see [2]), some contributors are still not respecting that model in WD but the structured data of WD allows you to eliminate everything you don't want. Just be aware that more you increase your constraints, more the filter is complex and less data will fit your desire. That's all.

Snipre (talk) 07:50, 16 July 2019 (UTC)

It's very easy to filter values that use P143 "imported from Wikimedia project". It's also very easy to filter values that only use a very defined set of reliable sources. It is not easy, however, to get anywhere in between, because you'd need either a comprehensive set of all reliable sources or a comprehensive set of all unreliable sources, and such a thing simply doesn't exist. Nikkimaria (talk) 11:48, 16 July 2019 (UTC)

I have experimented with reusing sources from Wikidata, and it is quite easy to make a minimum implementation. It is although a bit hard to make something that truly look like the current cite templates. It is not hard at all to filter out statements that use P143, but it is strangely difficult to explain to users that this is easy and in fact was done in the experiment. Jeblad (talk) 19:57, 16 July 2019 (UTC)

Thank you for the comment. This is my point too: we can filter everything which doesn't comply with the English WP rules concerning the lack of source or circular WP references. But as WP English is not able to provide the list of reliable sources for the whole WP, this is no reason to ask the same task to WD. If someone want to extract only values from reliable sources, then he has to provide the list of reliable sources. This can then be added in the infobox code (if the infobox is codded in lua of course). Snipre (talk) 11:59, 16 July 2019 (UTC)

Infoboxes are mostly irrelevant on the English Wikipedia for this use case, at least for now. Most of the Wikidata usage on the English Wikipedia still comes from the authority control, official website and Wikimedia Commons templates (as well as some other external identifier templates). It's still exceptionally rare to see infoboxes that use any substantial amounts of data from Wikidata, and I don't expect this to suddenly change.

Conveniently, if this remains the case until Wikidata's sourcing situation generally improves, it means that sourcing is also almost entirely irrelevant for the English Wikipedia, because external links and Commons categories don't require sources. I do also think it would ultimately be necessary for the software to show sources if it's ultimately intended for everything in infoboxes to be based on Wikidata data, but it might take a lot of user testing to make it more usable than the figure-all-of-it-out-yourself style of the current wikidata.org/Wikibase interface. I don't think this sort of user testing would be appropriate for the minimum viable product, though, especially if it'd be initially implemented as a beta feature (i.e. lower risk of vandalism and errors).

It could be possible to make the case that because the English Wikipedia convention is to omit sources from infoboxes altogether, it wouldn't make sense for sources to be shown in the pop-up anyway (though in my view it would probably make more sense to require sources for all infobox data).

I also take issue with your suggestion that Wikidata would have to be considered as a whole. As an example, if census data were imported regularly for a particular country (making it acceptable to use that data in infoboxes), it wouldn't make sense to require a complete evaluation of Wikidata just to use that census data.

I'm still not sure why you're implying that this software being unable to handle references would cause a huge fuss, given that it would be the conscious and deliberate decision of template authors to enable the software for the appropriate parameters; presumably, if it's considered absolutely necessary for the end user to view the sources, then the pop-up would just be disabled for the relevant data. I'm sure it's perfectly possible for this to become contentious if it's not handled properly, but it doesn't seem likely to me because it's (presumably) not going to be forced on anyone and editors are (presumably) to be completely in control of where and when this gets enabled. Jc86035 (talk) 16:34, 9 July 2019 (UTC)

Of course, Wikidata data is actually used in infoboxes in a significant number of Wikipedia editions, so (as Snipre notes below) this would not be applicable for some of the larger wikis like the French Wikipedia, and in most situations it would be necessary to be able to view, add and modify references through the pop-up. Jc86035 (talk) 14:04, 16 July 2019 (UTC)

Hey :)

Yes. It'll be up to the template editor to decide where to use the Wikidata Bridge.

Also our designer is currently figuring out how to handle references. So we'll have that as well. Lydia Pintscher (WMDE) (talk) 13:31, 11 July 2019 (UTC)

That sounds like a state of affairs where you would get a template editor to decide to use the Wikidata Bridge on EnWiki and then we get drama and an RfC which might put us in a worse position then we are currently. ChristianKl (talk) 15:55, 8 August 2019 (UTC)

Wikidata usage itself is already limited to non-infobox data that doesn't require references on almost all English Wikipedia articles. Only a few specialized infoboxes like w:en:Template:Infobox telescope use Wikidata extensively (though w:en:Template:Infobox person/Wikidata does have more than 1,800 transclusions). Given that it wouldn't make sense to use Wikidata Bridge without also using the relevant Wikidata data, I don't think this would in and of itself cause any drama; it's already discouraged to add Wikidata-transcluded data to begin with, so I doubt that anyone is going to be running around adding a beta version of Wikidata Bridge to high-use infoboxes.

Logically, there are only four scenarios for Wikidata/Wikidata Bridge usage for infobox data:

• The status quo, at least on the English Wikipedia is that infobox parameters generally have neither Wikidata data nor the Bridge pop-up.
• If one were to add only the Bridge code but not the data from Wikidata, the pop-up would probably be removed (or no one would notice) since it wouldn't be possible to use it to modify anything displayed in the article. This would probably cause disruption to the Wikidata data, but wouldn't in itself cause disruption to the Wikipedia article.
• The situation for adding data transcluded from Wikidata without the Bridge pop-up would presumably remain the same.
• If both data from Wikidata and the Bridge pop-up were added, would this be worse than if only the Wikidata data were added? The references not being shown, I think, would only be detrimental to Wikidata and not to the English Wikipedia, because references aren't normally shown in English Wikipedia infoboxes, and it's still not possible for w:en:Module:WikidataIB to display references in the first place. Jc86035 (talk) 16:20, 8 August 2019 (UTC)

It's not difficult to import the references, if desired, along with the values they support. The problem lies with how to format those references so that they match the style of the references used in the rest of the article. Unfortunately, the English Wikipedia allows an editor to make up whatever style of referencing they choose and once that becomes the established variant for the article, you need lengthy discussion to be able to change it. It's therefore a near impossible task to hold a list of all possible styles of reference formatting that imported references would need to match. The outcry from editors that "these references have appeared and I can't change them to fit my scheme" would set back the adoption of Wikidata on the English Wikipedia by years. RexxS (talk) 20:02, 6 November 2019 (UTC)

Tracked in Phabricator
Task T209242

Maybe I'm stating something that's already obvious or I've asked you this question already in some other discussion, but could you not have a parameter like |ref-style=cs1 and disable citations/Wikidata on pages without the parameter? Would there be a drawback in doing so, other than necessitating the use of the parameter? Jc86035 (talk) 13:08, 7 November 2019 (UTC)

The disadvantage is that editors will copy others who use the parameter, even on pages that don't use CS1. That's when the outcry starts and the blame goes to "Wikidata" or whoever implements the code, rather than the editor who made the mistake. Nevertheless, I suppose that we'll have to have something like it eventually, so I'll sandbox an implementation when I get back from this weekend's meeting. RexxS (talk) 08:40, 8 November 2019 (UTC)

I share some fears of Alsee about the risk that this tool will bring more criticism about WD. The main criticisms are the quality of the data and the integrity of the data. And the first draft of the tool didn't take account of these two aspects so there is a legitimate question to know if the developement team is aware of the opposition to the use of WD.

About the quality of data, the main element is the sourcing and some WP have some strong policy about that aspect. Proposing a tool which is not able to deal with that principle is just a casus belli because it encourages a bad behaviour in those WPs and can increase the risk to see the display of that data later by the WP if the infoboxes are not proper coded to filter the data.

Then about the data integrity, the fact to propose to correct "wrong data"is a bad understanding of the sourcing principle. If someone did a mistake when adding a sourced data with the property "retrieved" (P813), then by changing the value of the statment but not the value of that property in the reference part, we generate complete chaos in terms of chronology.

And finally no answer about the vandalism problem was proposed since the last RfC: no stronger policy about authorization of contributing (like excluding IP), no stronger policy about sourcing (like obligation to add a source), no increase of the protection of existing data (it is still possible to change the value of a sourced data without having any blocking or deletion of the reference part).

Just increasing the access to WD will just incease the vandalism posibilities and then WP having a strong concern about that problem won't be intereted to implement a that tool and further to use data from WD.

Snipre (talk) 14:09, 13 July 2019 (UTC)

Wouldn't sources presumably be made mandatory on a per-property basis using constraint violations (which Wikidata Bridge would have to be able to handle at least partially anyway)? I don't think it would be appropriate to implement such a requirement specifically for this tool, given that many properties (a majority if we include identifiers) shouldn't need sources in the first place.

I agree that it would be essential to manage vandalism, although if all the edits from the tool are tagged then it shouldn't be technically difficult to assess whether most edits are constructive and whether allowing unregistered users to access the tool is beneficial. As noted, the tool would also be enabled on a case-by-case basis (and it would be possible to mix non-interactive and interactive pencil icons in the same template), so if a template is disproportionately enabling vandalism then the pencil icon could be removed for that template. Jc86035 (talk) 14:30, 13 July 2019 (UTC)

Jc86035: "given that many properties (a majority if we include identifiers) shouldn't need sources in the first place". On which basis can you assert that the majority of properties don't required references ? This is the inverse, the majority of properties require a reference to be able to manage the chronology of information (even identifiers can change folloging merging in the original databases) and difference between several points of view.

In my opinion only instance of/subclass of and properties used to decribed a reference shouldn't have a source.

People think that identifiers don't require references, but htis is wrong, because some databases are not open so we can know those identifiers only using others sources, then even identifiers can change with the time due to merging in the original databases, so it is necessary to have at least a retrieved date with an identifier in order to understand why two references can have different values for the same identifiers (one if before the change and the other after). Some data can be different but all can be correct: we can have differences in the precision, in the method,...

And finally, to comme back to your comment, you explain that a tagging will be used to assess the vandalism risk, but this assuems a post treatment of the edits (who will do that, is ti a permanent action or only a temporary analysis,...) and this is based on the fact that we will be able to differentiate vandals from contributors in an easy way. So again the risk is not reduced at the origin but using permanent actions which will lead to an increase of workload for "good" contributors and will be depending on the effort of these contributors Wikipedians don't like this kind of arguments, they dont' want to know what we will do to improve WD, but what is currently active to keep the quality.

So again with the announcement of the Wikata Bridge, we have a similar process than the one for WDin the past: we are trying to sell a product with identified drawbacks with the promise that the tool will be improved in the future to take account of the customer needs. And the Customer answer is "come back later when your tol will do what we need". Snipre (talk) 10:08, 15 July 2019 (UTC)

Even assuming that it would be good practice for users to add metadata for identifier statements, given that "our designer is currently figuring out how to handle references", it would presumably be technically possible to make it easier to add retrieved (P813) and the UTC date as a reference for identifiers using a checkbox (of course, this is hypothetical, and it would be better if this and similar actions were possible in the Wikibase interface as well). Even if this isn't possible, it wouldn't be difficult to check an item's revision history if a conflict arises (and presumably this is usually necessary anyway, since most identifier statements don't have such references).

Although I agree that the prospect of increased vandalism is probably detrimental, it's possible that it would also be easier for readers who've never edited before to correct obvious vandalism (and easier for them to be introduced to editing Wikidata, and so on). Anecdotally, I've seen this happen on both Wikipedia and Wikidata. We would need to wait for the live trial to know if this actually has a measurable benefit, of course. Jc86035 (talk) 10:50, 15 July 2019 (UTC)

I agree about the fact that every problem can be solved with a solution, and this discussion is not about pointing the impossible things to acchieve. But the development team decided to find a solution to one particular problem (contributing to WD from WP) and forget to propose a solution for all other problems which are currently the sources of opposition to the use of WD in WP: poor quality data (data without source, data sourced from WP), fight against vadalism (no possibilty to use WP history of article to see modification in WD affecting the WP article), protection of integrity of data in WD,...

We all know this is a question of priorities and resources, that's not the point. The problem in the process used to propose a new tool which solved one problem (contribution to WD) but without having from the start a solution for the other problems. We can't change the current WD framework, but any new modifications should take account of the maximum of the criticisms mentioned previously in order to show that the problems were understood and that there is a will to solve them.

To summarize a little:

• the first beta version has to include a feature to handle reference. There is no interest from the big WPs (or at least no majority) to assess a tool without that feature
• no correction of existing statement should be possible without an update of all relevant qualifiers or reference properties. The critical point is the retrieve property which has to updated in any case. And finally the definition of correct or wrong for a statement can't be done without a look at the reference. Some data were correct once and not more currently. This doesn't mean that value was wrong all the time and perhaps in a certain period the data was correct. WD has to be able to take account of the fourth dimension (the time). Same for data with different units, and based on different determination methods. Unless the full data set including value, qualifiers and references can be displayed by the interface, there is only acceptable action when contributing to WD from WP: adding a new statement.
• finally, even if the interface tool allows new contributors from WP to edit WD, I can already predict that this source of contributions will be a problem for WD: the interface is not the main problem, the main problem is the addition of the whole data set linked to a value. Just look at the complaints of WD contributors: to add a reference, I need to create a new item with 2-5 properties or how data should be modeled (see the problem of date accuracy). How the interface will solve that ? I hope that the interest of WD will be taken into account and everything will be done to avoid a bunch of new statements without reference and without mandatory qualifiers, because this will just transfer the problem from WP contributors to WD contributors and I would not like to have to correct bad structured statements edited in WP. Snipre (talk) 13:50, 15 July 2019 (UTC)

I doubt this is correct the first beta version has to include a feature to handle reference. There is no interest from the big WPs (or at least no majority) to assess a tool without that feature

Most users (and communities) are willing to explore any solution to editing statements from Wikipedia, with or without sources from Wikidata.

The second point would set the bar muh higher for Wikidata than Wikipedia presently does, and I'm not even sure it is possible to enforce this at all. Not on Wikipedia, and not on Wikidata. It is possible to trigger warnings in some cases, like when a sourced document changes. Jeblad (talk) 20:13, 16 July 2019 (UTC)

Sorry but please add a reference to your affirmation "Most users (and communities) are willing to explore any solution to editing statements from Wikipedia, with or without sources from Wikidata". The three main WPs (en, fr, de) had RfC about WD use and put some constraints to the use of WD and the constraints were not related to the lack of possibility to edit WD from WP.

With Wikidata Bridge, there will be no change in the reasons which lead to limit the use of WD in WP. Some contributors are always ready to test new functionalties but if you don't convince the majority who emitted strong reserves in the RfC, then you will just see new constraints for the use of Wikidata Bridge. Is it what you want ? What are you proposing to avoid the criticismes already written in the previous discusisons ?

For the second point, there is no different treatments between WP and WD: WP always recommend to add source so WD Tools have to be able to edit references. You mix the possibility to add reference and obligation to add references. Wikidata Bridge doesn't need to force contributor to add sources but has to be able to provide a way to edit sources.

By delivering a beta version without possibility to edit sources, Wikidata Bridge will not comply with the recommendation of WP to add sources and will not take account of previous criticismes mentioning the poor data quality in WD mainly due to lack of sources. Snipre (talk) 08:42, 17 July 2019 (UTC)

Been involved in several discussions about Wikdata Bridge, and Wikidata in general, on several projects. (Betatesting at nowiki) The discussions goes as about ¼ is very vocal pro Wikidata, ¼ is very vocal against Wikidata, and ½ is pretty much indifferent but accepts use of Wikidata. The quarter of users against Wikidata usually claim they have way more support than they usually does, and more or less consistently claim their fringe problems are major problems. No, I don't buy it.

To recommend use of sources is one thing, but what you imply with Some data were correct once and not more currently. This doesn't mean that value was wrong all the time and perhaps in a certain period the data was correct. is way more than to simply recommend use of sources. Okey, so you back down and say it is no obligation to add references, good. It is a beta and will provide some functionality. More features will come in later updates, and will be defined by the devs and the communities involved in the betatesting. If that does not include enwiki, so be it. Jeblad (talk) 11:05, 17 July 2019 (UTC)

While I generally agree with what you've said, these issues are shared by the vast majority of existing Wikidata editing interfaces. Harvest Templates and Mix-n-match, for example, also do not add the "retrieved" property, and presumably have a much higher editing volume than this software will; and the wikidata.org interface is only limited by the existing property constraints and edit filters. Perhaps it would be inappropriate to make these things absolute prerequisites for the software's deployment, given that this wouldn't actually resolve the issues and that all the work to prevent these things could have almost no effect (given the existing editing volume). I think it would be much more effective to resolve these issues through a separate project that doesn't just involve one interface, but clearly the issues haven't yet been prioritized enough across the board, not just within the development of this software.

Moreover, given that existing software already suffers from these issues and that the situation doesn't change in this regard, the Bridge software could be a net positive in terms of vandalism/bad edits, since users would become less likely to click through to wikidata.org due to most pencil icons no longer linking directly to Wikidata items.

(From the Wikipedia point of view, even if a user adds just a plain URL as a reference, it's better than nothing and can almost always be fixed later. I would think this is pretty much the same for Wikidata.) Jc86035 (talk) 06:49, 16 July 2019 (UTC)

While vandalism is a relevant subject here, I think it would be appropriate to address label/description vandalism, especially since it seems to be more common than statement vandalism. Addressing it properly would probably save much more time for experienced Wikidata contributors than adding an elaborate and foolproof citation system to the Bridge software would, and would probably require less development time and less user testing.

Perhaps the easiest way to address this would be to enable the SHORTDESC magic word on all Wikipedias (if not all Wikimedia wikis) – it does bring a number of benefits, particularly that more detailed/helpful generic descriptions (e.g. for disambiguation pages, lists, categories) can be enabled with one edit to a high-use template, rather than a bot run over a million items every time a word should be changed. At least on the English Wikipedia, I think the template also makes it seem easier (even if it isn't actually easier) to make the descriptions for individual articles more detailed. Of course, it also pushes the liability for fixing a lot of description vandalism back to the Wikipedias, which is convenient in several ways. Jc86035 (talk) 07:00, 16 July 2019 (UTC)

I hope there will never be a decision to turn bad hacks for individual wikis like SHORTDESC into fully supported features. We should work on better (and by default) tracking of changes from Wikidata and deprecating those hacks, not on setting them in stone. stjn^[ru] 18:55, 1 August 2019 (UTC)

I do think it helps to some degree, even if only because most English Wikipedia editors would never have otherwise noticed the descriptions' existence (e.g. [:w:en:Talk:Witness (Katy Perry album)#"Best album"? w:en:Talk:Witness (Katy Perry album)#"Best album"?], as well as #Brief article description vandalism on the same talk page – the vandalism edits actually stayed on the Wikidata item for almost half a year in total, which is concerning) because most English Wikipedia editors don't use the wikipedia.org portal or the mobile site and don't edit Wikidata. On the other hand, I wouldn't advocate for the use of SHORTDESC on every project, simply because there are only a few wikis where maintaining the descriptions could be plausibly doable. Jc86035 (talk) 15:50, 2 August 2019 (UTC)

Remotely exporting Wikidata item labels as if they were article-descriptions was an extremely bad hack. The Foundation needs to ask the community before pulling stupid stunts like that.

Wikidata can happily go on it's own way as its own project, or it can be shoved down other wiki's throats and a mob will show up with torches and pitchforks wanting it burned to the ground. Alsee (talk) 15:03, 2 August 2019 (UTC)

Please moderate your post. Thank you. Jeblad (talk) 15:08, 2 August 2019 (UTC)

While I understand some of the feature requests, a lot of the features described in the above thread has very little to do with Wikidata Bridge. They add a considerable feature creep which may make the project unfeasible.

Wikidata Bridge should allow editing of a statements value in the first implementation. That is the core feature, and that is what should be the beta. Jeblad (talk) 20:19, 16 July 2019 (UTC)

Why is adding statements with sources a requirement that makes the project unfeasible? It makes the project more complicated but it actually means that it costs less political capital to deploy the feature. The whole Wikidata Bridge project is to make interaction with Wikipedia easy. It won't be if you burn political capital for the sake of making the project a bit easier on the technical level. ChristianKl (talk) 14:08, 8 August 2019 (UTC)

Note that I wrote “They add a considerable feature creep” in plural. Jeblad (talk) 18:31, 8 August 2019 (UTC)

"Wikidata Bridge should allow editing of a statements value in the first implementation." References and qualifiers are part of the statement so these fields have to be editable in the first version of Wikdata Bridge. Snipre (talk) 08:46, 17 July 2019 (UTC)

Statements value (Wikibase/DataModel#Values), or more precise the object in the w:semantic triple (subject–predicate–object). References and qualifiers are part of the statement, but not part of the value (object).

There are several layers in a statement, and most users does not have a clear understanding of how they relate. I should have been more clear. Jeblad (talk) 11:32, 17 July 2019 (UTC)

By "beta", are we referring to the first usable version (e.g. something that would presumably be enabled as a demonstration on one of the test Wikipedias), or the first version to be enabled on a real Wikimedia project through the Beta Features preferences tab (which would actually be able to modify Wikidata)? Jc86035 (talk) 08:49, 17 July 2019 (UTC)

We will have support for adding references in the first version that goes live on a Wikipedia. Before that there will be iterations on a test system, the first few of of which will probably not have it. We will not make references mandatory in the first release because I think that adds a burden that we should not add unless absolutely necessary (and I can be swayed by feedback on the first releases). We will start with rollouts on small to medium sized wikis that ask for it. I believe these are the right ways to go forward because at the end of the day it is in the hands of the template editors on-wiki to decide where they enable the functionality and where not so they are ultimately in control. I hope that helps clarify things. Lydia Pintscher (WMDE) (talk) 10:11, 6 August 2019 (UTC)

We don't we start with design iterations, till we have a design that properly supports sources and thus doesn't come with the risk of alienating Wikipedians? WMF and EnWiki relations aren't on a particular high currently and it's prudent to avoid actions that have the potential to inflame matters further.

Why code up a design that's not intended to go live on a Wikipedia? ChristianKl (talk) 13:56, 8 August 2019 (UTC)

Feedbacks from a local Wiki

Hi, I'm working on creating a local page and a local announcement on Persian Wikipedia, explaining all that is explained here and updating that page accordingly, I'll also request for discussions both locally and on here, I was wondering, since not all editors on Persian Wikipedia are required to be fluent in English, is it possible if I occasionally post a translation of user discussions on this page and reflect WMDE answers locally? Mohammad (talk) 17:02, 5 July 2019 (UTC)

Hello Mohammad, and thanks for all the work you're doing! Of course, we'll be happy to answer the questions from the Persian Wikipedia community. Feel free to add a summary of the discussions here, and I'll answer any questions you have.

When the page is ready, you can also add it in the list on this page. Lea Lacroix (WMDE) (talk) 19:54, 6 July 2019 (UTC)

I wonder if there should be a page with links to local pages on the individual projects. That could make it easier to track down important implementations, and also differences. Jeblad (talk) 12:40, 28 August 2019 (UTC)

Isn't there already one? @Jeblad Mohammad (talk) 12:51, 28 August 2019 (UTC)

Not that I know of… Jeblad (talk) 12:53, 28 August 2019 (UTC)

I started a list on Wikidata Bridge/Updates, section "Pages about Wikidata Bridge on other wikis", is that what you were looking for? Lea Lacroix (WMDE) (talk) 13:13, 28 August 2019 (UTC)

Limiting use of references

During preparations for use of references from Wikidata for dates, by extending w:no:Module:WikidataDato, we found that some items has a lot of references for birth dates. One of the “worse” is d:Q4295 which has 30 references. That is slightly over the top, and we (I) implemented a simple scoring mechanism for prioritizing a few important (4) references. If such a mechanism is in use in an infobox, then an edit to a reference might not be visible. It may also move a reference to a visible slot, or vacate a visible slot. If the next number of references is not above max number of entries, then a change to a preexisting reference will not make it invisible. The problem arise when the number of entries goes above max number of entries. I believe the solution is to score and limit the entries in well-defined functions instead of a project specific module. That makes it possible to figure out if a specific entry will be visible in the infobox after editing in the gadget.

Current code uses a best score of language of title, root domain of reference url, linked entity, and property use. Code without to much doc is at w:no:Module:References. The code will probably be extended with a few other functions. Jeblad (talk) 10:28, 28 August 2019 (UTC)

Thanks for letting us know, this scoring mechanism is indeed very interesting! I'm not sure at what point we can integrate it, but we'll keep in mind the need for sorting and selecting references. Lea Lacroix (WMDE) (talk) 12:04, 28 August 2019 (UTC)

About “I'm not sure at what point we can integrate it”, perhaps I don't understand you, but when the scoring and prioritizing is done in a module it is outside the gadgets knowledge and it can't predict how it will be done. If the same thing is done in the Wikibase Client lib for Lua, or a parser function, then the gadget can predict how the infobox will look like and act accordingly.

An alternate solution to automatic ordering could be to manually order the references, but that ordering must then be project specific, which would create additional work load on the users.

Note that my scoring solution is not especially good, it is just one of many ways to do this. It can be viewed as a winner-takes-all on Manhatten metrics, pretty straight forward. If we had better statistics an Bayesian estimator could give better results. Jeblad (talk) 12:36, 28 August 2019 (UTC)

Qualifiers as additional information

In some cases qualifiers are important. One notable use is in entries for spouse (d:Property:P26), or “ektefelle” at nowiki. See for example w:no:Knut Hamsun, where the row reads “Ektefelle Marie Hamsun (1908–1952)”. (Which comes from Wikidata in this case.) Jeblad (talk) 11:09, 28 August 2019 (UTC)

You're absolutely right, qualifiers often carry some meaningful information. We will investigate to find the best way to display them when it's necessary. Lea Lacroix (WMDE) (talk) 12:07, 28 August 2019 (UTC)

New prototype (integrating references)

Hello all,

Based on your previous feedback, we built a new version of the prototype, that includes showing and editing references. This v2 has been tested by our UX researchers during Wikimania, with a dozen of people. We are already working on a v3 that will integrate the suggestions of the interviewees, but we still wanted to share the v2 with you, so you can keep track on the evolution. So here it is!

As usual, please keep in mind that this is only a "click-dummy", faking real interactions and with only one user path available.

If you have any remarks or questions, feel free to answer on that thread. Lea Lacroix (WMDE) (talk) 11:59, 28 August 2019 (UTC)

This new version v2 of prototype is clearer than v1. However, I am wondering whether the retrieved date is autofilled (on clicking like in Wikidata) or editors have to fill it. May be one example can be shown. Jsamwrites (talk) 13:34, 28 August 2019 (UTC)

Hi @Jsamwrites, thank you for your feedback. Currently retrieved is not automatically filled, but that is on our list of features we'd still like to implement. Charlie Kritschmar (WMDE) (talk) 14:57, 29 August 2019 (UTC)

Seems like the template type is part of the work flow; image 8 and image 9. This must be stored at Wikidata as abstract types, as there are a lot of different ways to implement references. Local code must also be prepared to handle typeless references, as it will probably be a lot of references that lacks type for a long time.

I'm attempting to make code for figuring out which template is a likely match in w:no:Modul:Property map, but it isn't completed yet.

Note that some references has an implicit type by lack of specific information, even slight differences in some information, or even that the information could be lacking completely. A well-known example is newspapers that publish short versions of the articles on the net, and complete articles on paper. When users find the story in the paper they try to look the articles up on the web, and link to them, without realizing the web-version is shorter, and that specific information (the reason for using the article as reference) is missing.

Note also that a lot of references at Wikidata does not have required pieces of information, like “title”. We could run a citoid-bot to fill in titles, and perhaps some other fields, but until that is done (not sure if that will ever be finished) a fallback for cite templates are necessary. This can be implemented quite easily in Lua, but it must be done. Jeblad (talk) 12:11, 30 August 2019 (UTC)

Use on federated projects

I wasn't aware of this when posting my feedback to Wikidata's federation input discussion, but if we are using data from (and potentially donating data to) Wikidata on federated projects, it stands to reason that we may want to use a bridge to edit Wikidata within our UI (as well as any data items in our own Wikibase instance), just as you forsee it being done on your own sister projects. While I appreciate this isn't the focus at this time, perhaps it could be a possibility that you consider for the future? GreenReaper (talk) 19:42, 2 September 2019 (UTC)

Hello and thanks for your feedback!

Although we're developing the tool with the usecase of editing Wikidata from Wikipedia for now, we have in mind that this extension could be used on any Wikibase instance in the future. This could be used to edit the content of a Wikibase instance from one of its client wikis.

The usecase of being able to edit Wikidata's data from a external wiki (not part of the Wikimedia projects) is not part of our short-term roadmap, but it could definitely be considered in a more or less distant future :) Lea Lacroix (WMDE) (talk) 08:06, 3 September 2019 (UTC)

Thank you, Lea. As outlined in our policies, we have no wish to duplicate Wikipedia or other Wikimedia projects; rather, our goal is to complement them, and such a feature may assist in that. GreenReaper (talk) 20:19, 3 September 2019 (UTC)

Link to a new version of the prototype

Hello all,

I just updated the link to the prototype to a new version (v 3.0). Thanks to the feedback we received during and after Wikimania, we've been able to understand better what people need and improve some features.

Please note that this is still a "click dummy", with only certain reactive paths and areas where you can click on, not a full developed test system. If you get stuck, you can press "R" or click on "Restart" on the bottom right corner.

What changed:

• the reference section was updated to be more visible
• we added a new type of screen, "data type not supported", to warn users when a data type is (not yet) supported by the Bridge. You can access it by clicking on the coordinates.
• another new type of screen is permission screens, that you can test by clicking on the map. This kind of screen will appear only when the user is trying to edit something without having the permission. The text and display is still to be improved, feel free to give us feedback.

What we're still working on:

• cancel and save buttons for references
• path to Wikidata not included yet
• path to history not included yet
• license notice not included yet


Feel free to try this updated prototype and give us feedback!

For your information, we're running a bit late on the timeline that is presented on the overview page, I'll give you a more detailed update at the end of November.

Thanks, Léa Lea Lacroix (WMDE) (talk) 15:00, 7 November 2019 (UTC)

When someone type in "new" values (with or without ref, I don't care : I don't understand why there is such a debate, whatever) ; will the new value be "upranked", and the other pre-existent value(s) be "downranked"/deprecated ? Bouzinac (talk) 15:18, 7 November 2019 (UTC)

Thanks for your feedback. Editing ranks will not be part of the first version of the feature, but that's an idea we keep for later. Lea Lacroix (WMDE) (talk) 15:22, 7 November 2019 (UTC)

So there will be multiples values each times someone edit a property ? Bouzinac (talk) 15:24, 7 November 2019 (UTC)

If the user states that the value is wrong, the value will be changed in Wikidata - no new value will be added.

If the value is outdated, then yes the outdated value will be kept in Wikidata and a new one will be added. Lea Lacroix (WMDE) (talk) 15:31, 7 November 2019 (UTC)

But if the outdated value had a preferred rank, what will happen? The new value will be created with a normal rank and so won't be displayed in the infobox? Or the old value will be downranked and the new upranked? Or created with a normal rank? Ayack (talk) 15:45, 7 November 2019 (UTC)

So the outdated value should be automatically be downranked...let's hope it will be finally implemented Bouzinac (talk) 15:32, 7 November 2019 (UTC)

No, the outdated value should not be be downranked (it was true at a point in time), it's the new value that should be upranked. Ayack (talk) 15:40, 7 November 2019 (UTC)

Hello @Ayack and @Bouzinac, the idea is that we will down rank the previously preferred value to normal and set the newly added value to preferred instead. We will not be deprecating values from the bridge. If the former value was already at a normal rank then the new value will be set to preferred.

There is currently no option to just add an additional value of the same rank via the bridge. Charlie Kritschmar (WMDE) (talk) 10:52, 11 November 2019 (UTC)

References is now well highlighted. Is it possible to add multiple references from multiple sources? Jsamwrites (talk) 17:23, 7 November 2019 (UTC)

Hi @Jsamwrites, It will be possible to add multiple references from multiple sources. The current prototype doesn't represent this functionality well yet. Charlie Kritschmar (WMDE) (talk) 10:53, 11 November 2019 (UTC)

property def

Where will the definitions for mapping infobox fields to Wikidata properties be stored?

Is there a Mediawiki/Wikibase installation where a sample can be seen? Jura1 (talk) 18:46, 15 November 2019 (UTC)

Interesting. Wouldn't it be just the existing mapping? VIGNERON (talk) 20:54, 15 November 2019 (UTC)

Which is defined in various places .. Jura1 (talk) 12:06, 16 November 2019 (UTC)

It will be just like it is now: each type of infobox of each wiki can have a defined list of fields, usually defined in the Lua code. The Bridge will not change that, as it will only add a layer for editing the data. Lea Lacroix (WMDE) (talk) 16:59, 16 November 2019 (UTC)

How does "Bridge" guess which property/statement to edit? Jura1 (talk) 17:04, 16 November 2019 (UTC)

It is integrated in the code of each infobox. For example, here's the code of the infobox for fictional characters on Catalan Wikipedia. There is no guess here, it's defined by the infobox creators. Lea Lacroix (WMDE) (talk) 17:37, 16 November 2019 (UTC)

Does it work specifically with the format of the Catalan infobox or would it also work with other formats?

I think Krbot had some problems identifying all different ways infoboxes use to define this. Jura1 (talk) 17:41, 16 November 2019 (UTC)

The Catalan infobox is just an example. On the long run, the Bridge will be able to work with any format of infobox defined by the maintainers. During the first steps of the deployment, we may focus on the infoboxes used by the Wikipedia communities who will beta-test the feature. Lea Lacroix (WMDE) (talk) 17:52, 16 November 2019 (UTC)

How can I see if an infobox is supported or not? Jura1 (talk) 18:01, 16 November 2019 (UTC)

@Lea Lacroix (WMDE): would you check with the developers to find out where/how it's defined to be recognized by the extension? Jura1 (talk) 14:27, 18 November 2019 (UTC)

I don't understand what you want to know. It's way too early to check if an infobox is supported or not, as the feature is not even finished. Later, it will be deployed on some wikis, and the infobox maintainers will be able to activate the Bridge features for some or all infoboxes. What exactly should be recognized by the extension? Lea Lacroix (WMDE) (talk) 15:03, 18 November 2019 (UTC)

How does the extension know which property or statement goes with a value displayed in the infobox?

e.g. how does the extension get from the mother at ca:Harry Potter (personatge) to d:Q3244512#P25.

It must already be defined somewhere.

Would one need to insert a manual edit link in the infox? Jura1 (talk) 15:15, 18 November 2019 (UTC)

Yes. In the first version the Bridge will hook into the links that are used in edit pens like on this article's infobox. The template editor will need to make a small adjustment (adding a parameter to the link) for it to work but it's a minimal change. Lydia Pintscher (WMDE) (talk) 19:48, 18 November 2019 (UTC)

I agree with @Lydia Pintscher (WMDE) that we must assume that something must be changed/added on the infobox code to inform Bridge which are the properties (in plural) involved in a "conceptual block". The current demo infobox of telescope is not the best example to understand what are the properties/qualifiers involved in block of information, because each information concept in this demo respond to one property. I suggest you see as a reference (not as the objective for first version of Bridge!) this three cases.

Although solve any situation is not part of the first phase (btw, smart decission), we need to know the whole complexity of the structures shown in infoboxes, to be able to identify the new internal tools (mapping ?) or rules we need to build/have within infoboxes to make understable to others uses, as Bridge. Amadalvarez (talk) 06:31, 28 November 2019 (UTC)

Editing labels or values

I see a potential confusion with the pencil icon, does it edit the value of the statement or the label of the value? Currently on Catalan Wikipedia, and other projects using the same Wikidata module, it is used for labels missing in local language. See w:ca:Angela Merkel with an icon for English fall back "Polytechnic Secondary School Templin" and even "Q56230686" with no English label, or similarly w:se:Angela Merkel and w:ast:Angela Merkel.

Should we use two icons, for labels and values? Vriullop (talk) 17:40, 27 November 2019 (UTC)

The Wikidata Bridge will edit the value of the statement, not the label of the value. In the future, we could add a link to the item of the value on Wikidata (eg Polytechnic Secondary School Templin) but I don't see the tool being able to change or add labels, this would add more levels of complexity and make it difficult to understand for the users we're targetting (casual Wikipedia editors).

I agree that the identical icon is confusing, and we should think about how we want to organize it: maybe a pencil to edit the value, and something else to edit the labels? Lea Lacroix (WMDE) (talk) 08:18, 28 November 2019 (UTC)

Hi, Léa. I understand and agree that Bridge is oriented to change infoboxes values, not infoboxes labels.

However, when the value shown was in another language (because the local label of the value doesn't exist), Bridge editors will click to change, because their point of view would be "the value I'm seeing is not correct". Then, Bridge will show "the correct value in incorrect language". What can the editor do to enter the correct value in the correct language?.

In other words, how to enter missing labels in your language using Bridge.

If I do not explain so well, just tell me and I prepare an example.

Salut ! Amadalvarez (talk) 22:28, 28 November 2019 (UTC)

Thanks for describing the usecase, it is quite clear :)

For the first version of the Bridge, this case will not happen, because the tool will not be able to edit values are other entities - it will be only things like dates and numbers.

However, we will keep this usecase in mind for the next steps where we will start editing entities values. Lea Lacroix (WMDE) (talk) 10:30, 29 November 2019 (UTC)

Thanks. Then we sould think on changing the pencil icon, maybe indicating the language code of the fall back used: Polytechnic Secondary School Templin ^(en)<figure-inline></figure-inline> with "(en)" linked to labels and the pencil used by Wikidata Bridge for the value. Vriullop (talk) 09:31, 28 November 2019 (UTC)

Test environment for the Wikidata Bridge

Hello all,

If you want to follow the progress of the development team on the first version of the Wikidata Bridge, you can have a look at the test system.

First of all, a disclaimer: this is a live test environment, and the developers are working in real time on it, which means:

• it is not the final version that you will see onwiki
• some features are missing
• it may be broken or behaving weird sometimes
• the test wikis are almost empty and plenty of data is not there or needs to be created (items, properties)

This being said, here are the links that you can look at:

• https://en.wikipedia.beta.wmflabs.org/wiki/Wikidata_Bridge_Showcase is the showcase article on a Beta Wikipedia site, with a basic infobox where you can try the Bridge
• On https://wikidata.beta.wmflabs.org/wiki/Q540739 is the test item that is connected to the showcase page

Feel free to try it and click on the pen icon to open the Bridge pop-up. Please note that in order to be able to edit data, you need to be logged-in on Beta: for this you will need to use or create a dedicated account, that is not connected to centralized Wikimedia account.

To go more into details, here’s an overview of what features are already working on the test system, which ones are not working yet, and which one will not be present in the first version of the Bridge.

What’s already working:

• When clicking on the edit pen, instead of going to the Wikidata item, the Bridge pop-up opens
• When the editor opens the Wikidata Bridge for a value with datatype string, they can edit it from the Bridge pop-up. For all others datatypes, the editor is told that it is not possible yet and offered to go to Wikidata.
• For a value with datatype string, the editor can make an edit and save it, the change takes place on the Wikidata item. However, the new value is not immediately displayed (we’re working on caching issues), you will have to refresh the page to see the new value.
• It is only possible to edit statements having one value. When trying to edit a statement with several values, an error message appears.
• All edits made through the Bridge are tagged on Wikidata with the tag “Data Bridge” so they can be easily spotted in Recent Changes, etc. The edit summary is not very descriptive for now.
• References can be displayed but the format is ugly for now
• Template editors can adapt an infobox to add the “Bridge layer”. A draft of documentation is available here.
• Permissions: when the page is protected, the edit pen will not be shown. For all the other situations where editing should not be allowed (user blocked, etc.), an error message will be shown.

What we are currently working on in order to be ready for the first version:

• Ask the editor if they are updating or fixing a value and make the edit accordingly (for an update, a new value will be added and the rank will be changed; for a fix, the value will be overwritten).
• Inform editors that they are editing a different project under a different license.
• When trying to edit multiple values, special values (novalue and somevalue) or deprecated values, we will show editors an explanation and send them to the Wikidata item.
• Fix caching issues (update the page immediately with the new value).
• Link to the revision history of the Item to give editors a path to check and revert vandalism.
• Support for datatypes external ID and URL.
• Offer a way to Wikidata for adding and editing references on Wikidata.
• Better edit summary
• Better formatting of references

What will not be included in the first version, but potentially later:

• Editing of datatypes other than string, URL and external ID
• Editing of qualifiers
• Editing of special values (no value / some value)
• Reference editing/adding/deleting of existing references
• Adding a reference to new values
• Multi-value editing and viewing

The development will continue over the next few months, as well as discussions here to gather feedback. We will also update you about the wikis where we plan to roll-out the first version of the feature, if these communities volunteer to try it. See also: how to get involved.

Cheers, Léa Lea Lacroix (WMDE) (talk) 10:18, 12 December 2019 (UTC)