I'll rephrase it to include documentation!

I think acceptance criteria nr 2. is already broken out to this spike?: T436087 - Investigate release routine, right? @Marc_Maillard_WMSE @Sebastian_Berlin-WMSE

1. will be partly covered in this task: T430515 - Add accessible view for adding, selecting and editing profile, during the editing step.

In T436431#12301837, @Sebastian_Berlin-WMSE wrote:

I encountered a strange thing when setting POC on the preferences page (not our dialogue). When you check the box for POC its value in options (checked in browser console with mw.user.options) is "1". When you uncheck it it's false. However if you do the same with the setting for enabling highlighting you get true and "" respectively.

I see no reason why they should be different or why neither of them isn't just true or false. With the extra conversion we do it works and I don't think it should cause any issues. It does seem like very odd behaviour in MW.

In T435966#12297947, @Sebastian_Berlin-WMSE wrote:

@Viktoria_Hillerud_WMSE, do you have any thoughts on file structure on the servers? I'm in favour of using links so it's easy to switch between MW versions when we upgrade. Does this cause any issues or make things overly complicated? I think we haven't done so lately on at least some servers. This is a good opportunity to decide the structure and be consistent.

The new tool is up and running at: https://wikispeech-sdc-beta.toolforge.org/

For the second part, wikispeech-listen:

Starting with the first patch, the parameter handling (JSON boolean in sharedUserOptionSettings.js) :

Yes you're right. The parameter handling and listen not being told about the setting are unrelated, even if they touch the same grounds.

I've found something confirming that it isn't just as simple as an issue with sortable tables.

wikispeech-listen was never told whether parts of content was enabled. Segment hashes are decided from the text of the segment, and POC changes that text by inserting announcements like "länk:". A hash created with the setting on therefore does not exist in a segmentation done with it off. getUtteranceForRevisionAndSegment() always segmented without the setting, so it could never find the hash the client had been given. That is the "No such segment" RuntimeException.

I think this sounds like a really good setup and plan, what do you think @Marc_Maillard_WMSE ?

Now the attached images should be shown @Sebastian_Berlin-WMSE

There are a few things I've discovered now that I've been troubleshooting, and I've found where the biggest root problem was:

I also wrote that in the MR description, but I realize that could've been described here as well..

In T430515#12264877, @Sebastian_Berlin-WMSE wrote:

When you add a profile, the new design doesn't fit in the sidebar.

I wonder if we even want to show the profile list in this view. The version you get on mobile, with the back button, should work fine here too.

We've earlier set up our own test wiki (wikispeech-test.wmcloud.org), and to solve the Beta-Meta issue, I installed Extension:OAuth as an OAuth2 provider, and pointed both local dev and wikispeech-sdc.toolforge.org at it. Login now works against our own wiki instead of Beta Commons.