more motivation?

#38 sets up initial usage for sidebar managment

Strategy

• It seems to be ok to ask React to render multiple independent components on the page separtely - https://stackoverflow.com/questions/31302803/is-it-ok-to-use-react-render-multiple-times-in-the-dom
  • So one can try re-writing smaller components and replacing their rendering with React
  • combining things into a single unified tree as the process continues
• I haven't done such a migration before, so it'd be valuable to spend more time looking for strategies for this use-case in general

Questions

• Is there a need for state-management (redux-style) ?

think about more other possible variations

(for the record) Is the P8966 meant to be checked against raw URLs or against? I have raised this question at https://www.wikidata.org/wiki/Property_talk:P8966#regex_for_URLs_or_after_escaping%3F

Depending on the outcome of it the escaping in

Seven rules for perfect Japanese typography – 2. Don’t use italics.

Italics don’t exist in Japanese, but CSS italic rules will force an unnatural-looking oblique on Japanese text in some browsers. Use font weight variation or brackets to offset Japanese text as you would with italics.

I'm sure this applies to other languages as well.

Environment:
Firefox v84.0.1 on Linux.
This extension v0.132.
No other extensions enabled.

Steps to reproduce:

1. Close all instances of Firefox and start a new instance (Firefox starts with this extension side bar closed).
2. Login to Wikidata.
3. Open this extension side bar.
4. Open a new tab and navigate to an item on an external site e.g. IMDB.
5. Add a missing external ID to an existing Wikidata object using this extension side bar.
6. Note in Wikidata that the edit was done anonymously with the IP address showing, instead of being made with the Wikidata account logged into under step (2).

Would it be possible to warn users that the edit they're about to make would be done anonymously, and then provide information on what would need to be done to login to Wikidata?

It probably makes sense to do internal navigation for wikidata items/etc directly in sidebar.
But I think most of the external links should be opened in a new tab, this is especially relevant for an iframe version, as many sites balk at being rendered in an iframe =\

currently the width of the sidebar is reset upon navigation

List of steps to reproduce (step by step, including full links if applicable):

1. Load https://en.wikipedia.org/wiki/South_Pole_Telescope
2. Select 'The South Pole region' in the 'Microwave and millimeter-wave observations at the South Pole' section
3. Try to edit that section

What happens?:

• The edit link for the section disappears when you select the text

What should have happened instead?:

• The edit link should still remain visible

I originally reported this at https://phabricator.wikimedia.org/T303108 since I thought it was a MediaWiki issue, but it seems to only happen when using this extension. I'm using extension version 0.224 in Firefox 97.0.1 on Mac OS 12.2.1.

originally reported on the extensions talk page.

Currently all image links use http rather than https which shouldn't for pages using https work. Should be fairly easy to fix.

I've tried using Twitter search to add Discord invite IDs (P9078) for people with verified Twitter accounts. For example, this tweet would be usable as a reference. However, both on the search page and on the page for the tweet itself, I wasn't able to add a P9078 statement to Jonathan Mann (Q6273813).

(Even if I had been able to do this, I would have had to add qualifiers separately to avoid constraint violations.)

Right now when you click on any link/action in the sidebar there is no way for you to to a previous state, which is frustrating

Having a "back" (and potentially forward) button would be helpful.

Should be reasonably easy to do with Iframe version (#38) - https://stackoverflow.com/questions/3254985/back-and-forward-buttons-in-an-iframe/43334137

maybe like this?
https://stackoverflow.com/questions/10745564/track-only-iframe-history

the style of the website should be shielded from the sidebar and the other way around. the following screenshot is literally example.com:

the slide transition should not occur upon navigation

Currently the rendering of these statements as references looks somewhat like this:

reference URL: apnews.com/article/dmx-earl-simmons-dead-a9151285bb3e6334154afe4773d8b74f
title: Rapper-actor DMX, known for gruff delivery, dead at 50

at least these two statements should be replaced by a one liner:

Rapper-actor DMX, known for gruff delivery, dead at 50

When coming across the same page within minutes, it is possible to accidentally add the same identifier twice. I suppose this could be solved by caching the identifiers that were added for some minutes until the item is query for again, and it could be expected the update would have been picked up.

currently statements are only visible when they have a preferred rank or when they have a normal rank and no statement with a preferred rank is present. Subsequently, there is no need to display the qualifier reason for preferred rank

since bugzilla:1536094 seems to be fixed now, I would like to the whole application to use native javascript modules. That would not only make the code easier to read, it also allows us to use third party libraries like https://github.com/maxlath/wikibase-sdk

Right now you can only accept suggestions for the fields guessed by extension (and modify some of them), it would be great if I can add arbitrary new fields in that view as-well

resolver__regex.js currently contains a list of regular expressions the extract external-id from urls that contain them:

P345:  /^https:\/\/(?:www|m)\.imdb\.com\/(?:(?:search\/)?title(?:\?companies=|\/)|name\/|event\/|news\/)(\w{2}\d{7})/,
P8013: /^https:\/\/trakt\.tv\/(people\/[^\/]+|movies\/[^\/]+|shows\/[^\/]+\/seasons\/\d+\/episodes\/\d+)/,
P2002: /^https:\/\/(?:(?:mobile\.)?twitter\.com\/(?:intent\/user\?screen_name\=)?(?!hashtag)([0-9A-Za-z_]{1,15})|tools\.wmflabs\.org\/scholia\/twitter\/([0-9A-Za-z_]{1,15}))/,
P434:  /^https:\/\/(?:musicbrainz\.org\/artist\/|www\.bbc\.co\.uk\/music\/artists\/)([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})/,
P436:  /^https:\/\/musicbrainz\.org\/release-group\/([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})/,
P724:  /^https:\/\/archive\.org\/details\/([0-9A-Za-z@\._-]+)/,
P2969: /^https:\/\/www\.goodreads\.com\/book\/show\/(\d+)/,
P6327: /^https:\/\/www\.goodreads\.com\/characters\/(\d+)/,
P1651: /^https:\/\/www\.youtube\.com\/watch\?v=([-_0-9A-Za-z]{11})/,
P1821: /^https:\/\/\w+\.openfoodfacts\.org\/category\/((?:[a-z]{2,3}:)?[a-z-]+)/,
P5930: /^https:\/\/\w+\.openfoodfacts\.org\/ingredient\/((?:[a-z]{2,3}:)?[a-z-]+)/,
P2397: /^https:\/\/\w+\.youtube\.com\/channel\/(UC[-_0-9A-Za-z]{21}[AQgw])/,
P4198: /^https:\/\/play\.google\.com\/(?:store\/music\/artist\?id=|music\/listen\#\/(?:wst\/)?artist\/)(([A-Z]|[a-z]|[0-9]){27})/,
P4300: /^https:\/\/(?:music|www)\.youtube\.com\/playlist\?list=((?:PL|OLAK|RDCLAK)[-_0-9A-Za-z]+)/,
P5327: /^https:\/\/www\.fernsehserien\.de\/([^?#]+)/,
P3984: /^https:\/\/www\.reddit\.com\/r\/([^\/?#]+)\//,
P1733: /^https:\/\/(?:store\.)?steam(?:community|powered)\.com\/app\/(\d+)/,
P2725: /^https:\/\/www\.gog\.com\/([^#?]+)/,
P4477: /^https:\/\/www\.humblebundle\.com\/store\/([^#\?\/]+)/,
P1933: /^https:\/\/www\.mobygames\.com\/game\/([^#\?\/]+)/,

ideally these regular expressions should be provided by the wikidata community.

• A property should be proposed
• replace the list of regular expressions in resolver__regex.js with one queries from wikidata

The links view for what links to an item is a sink regarding linking between views, e.g., you cannot get back to the entity (outgoing edges) view. Additionally, the links view only links to the links view of the properties and items displayed on it. This can lead to confusion: When a selected item has an incoming link from an item with no incoming links, clicking on this item in the links view results in an empty screen. I would have expected to get to the entity view anytime I click on an entity.

I just tried to use the extension. I failed to add a single statement. I tried opening the Qid on wikidata.org and failed. I tried leaving feedback directly in the extension and failed.
In the end I went to wikidata and searched for "wikidata firefox" and found my way here to report.

I wonder. Have you done any user testing? Do you have a prototype in figma.com or similar tool that you used during development?

Cheers

displaying qualifiers is supported, but there is no way to add them in the "add view"

New sidebar implementation is missing the close button

repro: go to any page that does not resolve to an existing entity

• what is it?
• features?
• call for participation

Notes

• screenshot should not contain copyrighed material
• screenshots should not be included into the package

should be solvable with css vertical-align: top

Hi there,

I found the grey arrow in the UI not quite intuitive.

It would be great to amend the arrow with its meaning, either textual or graphical.

Cheers! Robert

Context

clicking the arrow currently flips the direction of the statement:

Before clicking the arrow	After clicking the arrow

• Reference URL (P854) of the current page
  • preferably with an ?oldid= parameter if the source is a mediawiki
  • preferably with a #hash of the section that contained the link
• section, verse, paragraph, or clause (P958) of the section that contained the link
• retrieved (section, verse, paragraph, or clause) with the current date
• title (P1476) of the page that contained the link

Right now the improve view will show you the current source extension is processing to discover the additional data, but it's not clear if it's found anything so far.

When working on #34 I accidentally disabled overlay and it allowed me to see that extension incrementally collects and shows fields found so far, which I believe provides a better UX (better in the moment feedback and ability to terminate early if you are happy with the results already found)

Just disabling overlay looks weird when nothing is found, but I imagine this can be done like:

• start with current overlay
• when first result is found transition into showing underlying "add fields" view with fields found so far
  • continue showing indication of the ongoing search on sidelines

Example: https://www.wikidata.org/w/index.php?title=Q110138137&oldid=1544732821#P2047

The addon adds episode durations accurate to the second, but the duration of an episode should be accurate to the minute. Take a look at the interface of trakt.tv, where the information is from. Even if they save it accurate to the second, the duration is always a round minute.

Expected behaviour: Check whether the duration is divisible by 60, if so, save the minute duration. In combination with 4806506 the example above would ideally lead to only one claim with 24 minutes and two references.

Right now each source is processed sequentially, but most of the time is probably spent on asynch operation like fetching data from APIs, so this can likely be significantly faster if we were to switch to doing it async for all the sources at the same time

I saw Gplv3 here https://addons.mozilla.org/en-US/firefox/addon/wikidata/

(think FB messenger bubble)

This is a bit more obtrusive, but increases probability of you actually using the extension. Probably should be configurable, so people who don't like it can disable it.

communication to wikidata should be handled through wikibase-sdk.

Steps to reproduce

1. open a thing not yet connected to wikidata and connect it
   
2. immediately after that, open a site, that should be connected to the same wikidata entity (i.e. on imdb open the Cast and Credts section)
   

Expected result

The extension should remember that the thing we have just connected since the website we have open now, also has the same id in its url:

Actual result

The extension has never seen that url before and thus does not know which Wikidata entity is associated to it, and the Wikidata api does not distribute that information yet.

Possible Solution

Add an additional layer of caching that does not only consider the current url but also the extracted id of the current url.

nothing happens for inline sidebar in FF when I select text.
I suspect - it can be a missing event handler somewhere 🤔

I cannot click the "Publish changes" button when editing Wikidata/Wikipedia with this extension enabled.

I'm positively surprised by the fact that it loads in a first place :p, it crashes though, as the PDF document has a different dom structure (does it even have a dom?) and so when we try retrieve title/etc findApplicable fails

Steps to reproduce

1. enable the application
2. open any website that does not resolve to a wikidata object; e.g. https://www.urbandictionary.com/define.php?term=foo
3. click any link in that site; e.g. homie
4. click the browser back button

Expected result

browser should return to https://www.urbandictionary.com/define.php?term=foo

Actual result

nothing happens.

when clicked again, the back button will navigate to the correct site.

Environment

Firefox 96.0.3, macOS 12.1 (21C52)

Example use-case: https://twitter.com/VladyslavSitalo/status/1462908339860430855

Depends on #34

Tasks

• Remove dependency on browser api so it can be used outside the context of the extension
• Potentially have several layers of resolvers (node compatible, browser compatible)

Considesations:

• can keep code in the same repo (making this a monorepo) potentially simplifying code management initially but potentially making future contributions harder
  • Or extract into a separate repo
• License: using a more permissive license (MIT, Apache, etc) is IMO a better approach for the library
• It'd be nice to have a single interface for accessing the resolvers (e.g. a set of functions) (vs current situation where users have to iterate through all resolvers)

The current behaviour is for it to suggest creating a new entity, and the in the connection dialog show some potential matches (which are often accurate).
Which on one hand encourages adding missing information (good), but provides less immediate utility value (bad?)

So maybe one option would be to display guesses more prominently, while clearly indicating that it's a guess and that you can "connect" the page to solidify the match

Example: https://www.wikidata.org/w/index.php?title=Q110042758&oldid=1541787263
The addon is adding the statement P31:Q21191270 (is a: television series episode) multiple times. The expected behaviour would be to check every time if the statement is already existing, and if so, to add the statement only one time and add the references to the already existing claim.

Right now it's quite cumbersome. Some things that I think can improve the experience:

• Merge add view into the display view
  • Basically allow people to click a plus button in the bottom and add an arbitrary field (repeatedly)
  • Do the on-the-page entities discovery fully async
• Allow connecting entities that are not found from the page (via direct id entry, and via search)
• Don't push the buttons out of screen view (esp when there is enough space)
• (current add view) Add a signifier that indicates that it's possible to change the field type you're adding

Issues to fix:

• If none of the links resolve to anything the add view is forever stuck in the "waiting" state

currently there is just a headline and nothing else even if there are forms.

At minimum the URL of the page and retrieval time should be added. If the statement already exists then instead of duplicating it add this as a new reference.

A more sophisticated approach would be to let the user indicate where on the page the statement is claimed and link to that section direccly

@fuddl you mentioned potentially running reformat on the whole codebase after #38 is merged. This is to coordinate on the config/which rules should it enforce.

or

Let's not have unnecessary semicolons & other questions of taste 😛

Thoughts on adding a feature which captures google search / bing knowledge panels as identifiers?

For example:

• Google/Bing search "NEA" (national education association)
• Google shows a knowledge panels on the right
• This extension identifies that the current page is "about" Q3111510 via the knowledge graph identifiers on page
• Allows me to add properties from the page e.g. their twitter

This would require special handling for these URLs since they don't properly embed the graph id on this page.

I would be willing to code this feature if it's deemed acceptable.

Twitter usernames (for example) are case insensitive. If I tell the plugin to link a twitter handle to an item and the same handle is already present (but in a different case) it should not add the redundant case. You can detect whether a property is sensitive to case by checking for "has quality" "case insensitivity".