What we want now, is to update the $errorMessageKeys (which should probably be renamed to just $messageKeys) array in preSynthesizeMessages.php to contain all of the decided message keys from T407346 - Page toolbar, T407348 - Link-section and T407347 - Sidebar menus.

Yes, ofcourse! Right now, I only took some of the text from the help page itself but I can investigate more if this is what we want

I agree that it makes sense to accept a few small issues in the first version, especially since text interactions can work so differently in different browsers. And since we don’t really have a good way to test in Safari, I guess there will always be some edge cases we can’t catch right away.

I've resolved the issue by updating the local Node version to v23.3.0, which works with the new minimum requirement (>=20.11.0) introduced by eslint-plugin-jsdoc@61.x, used by eslint-config-wikimedia@0.32.x

I realized that this task, T405330 and T395320 are more connected than I first thought. I've been thinking if it would be better to actually write a shared dialouge-base to minimize duplication, but then I realize that all the dialogues does different things anyways, so it might still be better to create a new module for this task anyway.

If we only want to get one message at a time, when needed (e.g when a user mouse over an element), how can you get the message-key from the HTML? The HTML output does not expose the message keys directly, only the rendered text.
Is there a way in an API-call to call it with ?useLang=qqx and then collect the message keys from there or is that just for rendering full pages (e.g. via action=parse)?

I was finally able to finish what I started last week regarding breaking logic out from ApiWikiSpeechReportPronunciation to RemoteWikiPageProvider and also created a helper class for inserting a row to a table end.
This new class is pretty small, so it maybe a bit unnecessarily to have it, but I can't really think of having it anywhere else.

I think changing the mouse cursor to "progress" and the buffer animation sounds like a good idea.

Now it should finally work. From what I could read fro the documentation the way to go was to manually add the extra rights to the sysop when needed.

Oh.. I had reset the user group's rights on the demo wiki using $wgGroupPermissions['user'] = []; to ensure ordinary users can't edit anything, so I think I removed it all..

My bad! Seems I had set it an extra time in Localsettings.php (no idea why) so now it works with getConfig()->get()
Now I can continue breaking it out to RemoteWikiPageProvider

I can’t get $this->getConfig()->get('WikispeechPronunciationErrorReportPage') to read the value from extension.json.
I always get a "missingtitle" error, but if I hardcode the page title in the ApiWikispeechReportPronunciation.php, it works as expected.
So, config loading via extension.json seems broken for this variable, and I don’t understand why.

That's true. I think in that case that the function saveToExternalWiki() (that now lives in the API), then instead should live in RemoteWikiPageProvider, but the helper method: insertRowIntoReportTable() should be in a separate helper class.

After further reflection, I think its better not to extend RemoteWikiPageProvider with editing functionality.

Oooh... :/

Do you think there needs to be text rather than just the play icon?

Maybe, but that means that more text will appear on the screen, and I am not so sure if that is user-friendy.. Either way, I think the "button" that appears should clearly be signaling that: "Do you want to start playing from here?"

Yes, thanks! Then I think this is done!

The only thing I can find to remove in producer and demo wiki is this:

Looks good! I would also suggest that the best approach is to extend the existing selection player with this functionality, if possible.
However, if it turns out to be too complex, then creating a separate module might be a better alternative.

So I guess these are the only options we want to have:

This one depends on what namespace the page is in. For instance on ENWP it's "Article" in the main namespace and "Help page" in the "Help" namespace.

Hmm not sure what you mean? Or at least I can't find the correct i18n-message for this?

Sounds reasonable, I'll add that extra column

In T407346#11391024, @Sebastian_Berlin-WMSE wrote:

In T407346#11388249, @Viktoria_Hillerud_WMSE wrote:

"vector-view-create": "Create",

There's also "Create source"

Ah thanks! Found it: visualeditor-ca-createsource

Here are the relevant i18n-messages for the page-toolbar:

In T318775#11387591, @Sebastian_Berlin-WMSE wrote:

No, but we probably should start making note of them. I think there were one or two during the user test.

The saveOption() directly solved the issue where it didn't first write to preferences, but now it does.

I agree that using external services can easily complicate things. Do we have a list of the common segmentation issues we're currently seeing that we could start addressing?

Finally I understood the complexion of consumer vs producer. When adding gadget-template.js (from the repo) to the User:<your-name>/global.js and set producerUrl = 'http://localhost:8080/w'; we're explicitly telling the consumer wiki (e.g. Wikipedia) where the producer is located. Testing this setup on Wikipedia, I was able to reproduce the issue where the request was incorrectly sent to the local wiki API instead of the producer.

In T395320#11383017, @Sebastian_Berlin-WMSE wrote:

I've gotten it to work locally. It required creating the page first and adding the table to it. Before that I received non-specific error: "Pronunciation error report could not be saved.". I think it would be easiest to just add some instructions for this for now. I may be wort to automate to some extent in the future.

I have been poking around in the code quite a bit now, to separate the logic from when locally reporting and externally reporting an error.

Also, this is pretty much the same as the gadget solution, and maybe we would also want other or different settings from what the gadget has now.

In T405330#11371388, @Sebastian_Berlin-WMSE wrote:

...or this https://doc.wikimedia.org/mediawiki-core/master/js/mw.Api.html#saveOption.