"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 :)

In T235753#5674720, @Lucas_Werkmeister_WMDE wrote:

"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.

In T235753#5674828, @Addshore wrote:

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?

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

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

In T235753#5804709, @Pablo-WMDE wrote:

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.

• $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

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!

• $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

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.

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!).

In T235753#5805334, @Lucas_Werkmeister_WMDE wrote:

• $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

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.

identifier	name (en)	name (de)
string	String	Zeichenkette
monolingualtext	Monolingual text	Einsprachiger Text
wikibase-item	Item	Datenobjekt
math	Mathematical expression	Mathematischer 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?

In T235753#5810011, @Pablo-WMDE wrote:

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.

In T235753#5810039, @Lucas_Werkmeister_WMDE wrote:

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.

In T235753#5819595, @Lucas_Werkmeister_WMDE wrote:

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?

That would work, yes.

@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.

In T235753#5852246, @Lucas_Werkmeister_WMDE wrote:

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