Page MenuHomePhabricator

Step 1: Bail-out path for unsupported datatypes (impact: high)
Closed, ResolvedPublic8 Estimate Story Points

Description

As an infobox editor I want to be able to edit every value in the infobox in order to make sure that all the information is correct

Problem:
The bridge currently doesn't support some datatypes, so we need to give the editors a way to be able to edit the data via a different path

Example:
We want to do this by giving them solutions when the bridge doesn't work. They could make the edit on wikidata directly or do a local overwrite. For both these options we should be providing a path.

Screenshots/mockups:


(text not updated in mobile mock. please check desktop mock for reference)

Please find mocks in this Figma artboard.

BDD
GIVEN a bridge-enabled infobox field
AND it is connected to a Property of a datatype that is not supported yet
WHEN clicking the edit pen
THEN the modal opens and shows a message telling the editor to edit on the repository

Acceptance criteria:

  • when opening the bridge for a value with an unsupported datatype the UI should show what's in the mock instead of the usual UI
  • (blue button) the link leading to the repo is the same link that the edit pen uses and opens in a separate tab
  • "the article editor" link leads to whatever editor of the article the person is using
  • "publish changes" button is removed

Copy

Error message: Editing the datatype $datatype is currently not supported
Description: $property is of the datatype $datatype on $repoName. Editing this datatype is currently not supported.
Section title: Instead you could
Bullet point 1: Edit the value on $repoName. Click the button bellow to edit the value directly (link opens in a new tab).
Button label: Edit the value on $repoName
Bullet point 2: Depending on the template used, it might be possible to overwrite the value locally in the wikitext. If at all possible, we recommend that you instead add the value to $repoName via the button above.
Link for "in the wikitext":

Details

Related Gerrit Patches:
mediawiki/extensions/Wikibase : masterbridge: fix vertical marging of bailout heading
mediawiki/extensions/Wikibase : masterbridge: show property labels in bailout components
mediawiki/extensions/Wikibase : masterbridge: fix vertical spacing of ErrorUnsupportedDatatype
mediawiki/extensions/Wikibase : masterbridge: fix horizontal spacing of ErrorUnsupportedDatatype
mediawiki/extensions/Wikibase : masterbridge: Add header and body messages for unsupported data type

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Charlie_WMDE updated the task description. (Show Details)Nov 12 2019, 2:26 PM
darthmon_wmde set the point value for this task to 8.Nov 19 2019, 10:49 AM

"in the wikitext" link leads to the wikitext editor of the article

( new mw.Title( mw.config.get( 'wgPageName' ) ) ).getUrl( { action: 'edit' } )

EDIT: Actually, this can give you the VisualEditor if that was the last one you used. If we always want a wikitext editor, we might need other/additional URL parameters. veaction=editsource always gives you the VisualEditor wikitext editor, but is ignored when combined with action=edit, and if we only specify veaction then on wikis without VisualEditor installed the action will be “view”. action=submit can be used to bypass VisualEditor (and should work on any wiki), but isn’t very nice (users might not expect the non-VisualEditor wikitext editor to be used).

My only additional thought about this ticket is the sentence:

overwrite the value locally in the wikitext

Perhaps UX should have another pass over this bit of text, (I could be wrong but):

  • Users can use visual editor to do this maybe? so they don't need to use wikitext?
  • Is wikitext the correct thing to say? or should this say article/page source?

I'm sure the wmf frontendy people might have some sort of standards here, perhaps.

Haha, I had this comment written during the meeting and just saved to find the one by @Lucas_Werkmeister_WMDE here too :)

Charlie_WMDE updated the task description. (Show Details)Dec 3 2019, 2:57 PM
Charlie_WMDE updated the task description. (Show Details)

"in the wikitext" link leads to the wikitext editor of the article

( new mw.Title( mw.config.get( 'wgPageName' ) ) ).getUrl( { action: 'edit' } )

EDIT: Actually, this can give you the VisualEditor if that was the last one you used. If we always want a wikitext editor, we might need other/additional URL parameters. veaction=editsource always gives you the VisualEditor wikitext editor, but is ignored when combined with action=edit, and if we only specify veaction then on wikis without VisualEditor installed the action will be “view”. action=submit can be used to bypass VisualEditor (and should work on any wiki), but isn’t very nice (users might not expect the non-VisualEditor wikitext editor to be used).

I filed T239796: Provide URL parameter(s) to always load a wikitext editor to get some insight into this.

darthmon_wmde renamed this task from Bail-out path for unsupported datatypes to Step 1: Bail-out path for unsupported datatypes.Dec 5 2019, 1:06 PM
Sarai-WMDE updated the task description. (Show Details)Dec 6 2019, 4:42 PM
Lydia_Pintscher renamed this task from Step 1: Bail-out path for unsupported datatypes to Step 1: Bail-out path for unsupported datatypes (impact: high).Dec 8 2019, 1:19 PM
Charlie_WMDE added a comment.EditedDec 9 2019, 10:52 AM

My only additional thought about this ticket is the sentence:

overwrite the value locally in the wikitext

Perhaps UX should have another pass over this bit of text, (I could be wrong but):

  • Users can use visual editor to do this maybe? so they don't need to use wikitext?
  • Is wikitext the correct thing to say? or should this say article/page source?

I'm sure the wmf frontendy people might have some sort of standards here, perhaps.

that's a really good point. thanks adam. I am not sure about being able to use the VE to overwrite. is that possible?
using wikitext might not be the right word. it looks like maybe we should say something like "article source page"? do you know who i could ask about this?

Pablo-WMDE added a subscriber: Pablo-WMDE.EditedJan 15 2020, 11:17 AM

During task break-down we assumed:

  • that the application header shown in the mocks is not in scope (i.e. that there in fact will be an x-button, disabled save button, and header text as it currently stands - we will not touch this in this story).
  • $datatype will be shown as the datatype identifier (as used in code), not their translatable names as seen in e.g. https://www.wikidata.org/wiki/Special:ListDatatypes
  • we check for permission errors first and only offer the bail-out path if there are none

/cc @Charlie_WMDE @Lydia_Pintscher stop us if we are wrong

Charlie_WMDE updated the task description. (Show Details)Jan 15 2020, 2:34 PM

Heyho! thanks for bringing this up @Pablo-WMDE ! I'll comment inline.

During task break-down we assumed:

  • that the application header shown in the mocks is not in scope (i.e. that there in fact will be an x-button, disabled save button, and header text as it currently stands - we will not touch this in this story).

This is a mistake on my part in the mocks. The x-button should stay as is, that's correct. The "publish"-button shouldn't be disabled but should be removed entirely. I have updated the mocks accordingly.

I don't know how these two differ. Could you give me some examples? I think i was assuming we'd be using the translatable names.

  • we check for permission errors first and only offer the bail-out path if there are none

correct!

I don't know how these two differ. Could you give me some examples? I think i was assuming we'd be using the translatable names.

identifiername (en)name (de)
stringStringZeichenkette
monolingualtextMonolingual textEinsprachiger Text
wikibase-itemItemDatenobjekt
mathMathematical expressionMathematischer Ausdruck

The x-button should stay as is, that's correct. The "publish"-button shouldn't be disabled but should be removed entirely. I have updated the mocks accordingly.

i.e. the header is not out of scope, our assumption was wrong, and the header needs to be touched (just with based on slightly optimized specification). I'd appreciate if we could get an AC for such a substantial addition (on top of the mock, thanks!).

Charlie_WMDE updated the task description. (Show Details)Jan 16 2020, 4:48 PM

I don't know how these two differ. Could you give me some examples? I think i was assuming we'd be using the translatable names.

identifiername (en)name (de)
stringStringZeichenkette
monolingualtextMonolingual textEinsprachiger Text
wikibase-itemItemDatenobjekt
mathMathematical expressionMathematischer Ausdruck

thank you Lucas. how much more effort would it be to show the translatable names? or is it the same and you would just need to know which one to use?

The x-button should stay as is, that's correct. The "publish"-button shouldn't be disabled but should be removed entirely. I have updated the mocks accordingly.

i.e. the header is not out of scope, our assumption was wrong, and the header needs to be touched (just with based on slightly optimized specification). I'd appreciate if we could get an AC for such a substantial addition (on top of the mock, thanks!).

done! sorry about that. if this tickets needs re-estimation after the clarifications we can take it back to the next story time.

thank you Lucas. how much more effort would it be to show the translatable names? or is it the same and you would just need to know which one to use?

It probably means we need to make an extra API request to get the interface message for the name (datatypes-type-___). It’s definitely more development effort too, though I’m not sure how much.

thank you Lucas. how much more effort would it be to show the translatable names? or is it the same and you would just need to know which one to use?

It probably means we need to make an extra API request to get the interface message for the name (datatypes-type-___). It’s definitely more development effort too, though I’m not sure how much.

I think this is an enhancement which nicely lends itself to be split out into its own story and - in the spirit of living up the M in MVP - could be deferred to day 2 without any loss in functionality and with only minor impact on convenience. Using the datatype identifier as a placeholder text should be quite telling in itself and we could even add a deeplink to the thing on the repo (example) /cc @darthmon_wmde

I think the screenshot is a bit ambiguous in terms of the message. The beginning of the first bullet point, “Edit the value on $repoName”, could be a sentence of its own, but also a continuation of the previous text, “Instead you could”. That’s not going to be the case in all languages, though – which version should it be in that case? For example, which of these two German translations would you expect?

Stattdessen kannst du

  • den Wert auf $repoName bearbeiten.

Stattdessen kannst du:

  • Bearbeite den Wert auf $repoName.

This matters for us because if it’s supposed to be one sentence (as in the first German version), then I think it also needs to be one interface message, to avoid lego. Which means at least the paragraph above the list and the beginning of the list is one message, and then the rest of the list probably also needs to be one message, with the button/link as an argument that we pass into it. On the other hand, if it’s two independent sentences, then the header, first bullet point, and second bullet point can be three separate messages, with the button going between the second and third one. (The button’s own text would be a separate message in either case, I think.)

The second bullet point already doesn’t work as a continuation of the “Instead you could” sentence beginning, so it might make sense to make the first bullet point separate too, I think.

The second bullet point already doesn’t work as a continuation of the “Instead you could” sentence beginning, so it might make sense to make the first bullet point separate too, I think.

Yeah, that makes the most sense to me as well. But that might be @Charlie_WMDE's call as the person in charge of the copy.

@Lucas_Werkmeister_WMDE what if we change the copy to "instead you could do the following:". then all bullet points and the header message could be separate, right?

@Lucas, okay then let'S go with that. i'm gonna update the mocks

Change 568983 had a related patch set uploaded (by Tonina Zhelyazkova; owner: Tonina Zhelyazkova):
[mediawiki/extensions/Wikibase@master] bridge: Add header and body messages for unsupported data type

https://gerrit.wikimedia.org/r/568983

Change 568983 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: Add header and body messages for unsupported data type

https://gerrit.wikimedia.org/r/568983

Hello!

the margins on the right side of the modal are not correct yet in the top part. as you can see in the bottom, there's an additional 24px margin around the main element, plus the 16px that go all around the modal.
the text of the top section is going over the line as you can see in the screenshot, but it should have the same restriction.

(the mock in this tickets isn't really up to date but the figma link shows the correct margins)

Change 570097 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: fix horizontal spacing of ErrorUnsupportedDatatype

https://gerrit.wikimedia.org/r/570097

Change 570098 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: fix vertical spacing of ErrorUnsupportedDatatype

https://gerrit.wikimedia.org/r/570098

Change 570097 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: fix horizontal spacing of ErrorUnsupportedDatatype

https://gerrit.wikimedia.org/r/570097

Change 570098 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: fix vertical spacing of ErrorUnsupportedDatatype

https://gerrit.wikimedia.org/r/570098

@Lucas_Werkmeister_WMDE

sorry to be the party pooper. I found these very strange margin sizes (should be 16 at the bottom and 24 on top). do you know what's causing them? in other places i get the correct 8/16/24px so it can't be purely a conversion thing i guess

Ah, I see – seems to be the same issue as the one fixed in fix vertical spacing for the button: the element (in this case, the heading) has a font-size, which throws off the size of the margin.

So either we apply the same fix (scale the margin appropriately to cancel out the font size), or we rethink this whole px-to-em business, because at least I don’t understand it at all.

So either we apply the same fix (scale the margin appropriately to cancel out the font size), or we rethink this whole px-to-em business, because at least I don’t understand it at all.

I'm in favor of rethinking it. I have an idea in mind, let me see if can get a patch up quickly.

Uh, another thing… we still need to pass the property label into the message, rather than the property ID. IIRC we said during code review that we were going to do that in a separate change – well, we still have to do it :)

Change 570634 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: WIP: show property labels in bailout components

https://gerrit.wikimedia.org/r/570634

Change 570634 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: show property labels in bailout components

https://gerrit.wikimedia.org/r/570634

Change 570921 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: fix vertical marging of bailout heading

https://gerrit.wikimedia.org/r/570921

Change 570921 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] bridge: fix vertical marging of bailout heading

https://gerrit.wikimedia.org/r/570921

Charlie_WMDE closed this task as Resolved.Mon, Feb 10, 9:48 AM
Charlie_WMDE claimed this task.
Charlie_WMDE moved this task from Verification to Done on the Wikidata-Bridge-Sprint-13 board.

lookin good!