So say if we add it so that:
When a user selects and marks a word, and then clicks on the megaphone, they will for example come to this page?:
Extension:Wikispeech/Pronunciation_errors/sv

Where a new row with prefilled cells appears?

Or we don't want them to redirect at all to this page, and instead build a new special page?

I think that if it's possible to do it with a normal page that's preferable. If we make it a Special page we need to figure out how to display and store everything.

In T395320#10904021, @Sebastian_Berlin-WMSE wrote:

I think that if it's possible to do it with a normal page that's preferable. If we make it a Special page we need to figure out how to display and store everything.

Ok, so maybe keep this as the page that the users redirects to then? https://www.mediawiki.org/wiki/Extension:Wikispeech/Pronunciation_errors/sv

There should be a few place on various wikis that has a similar process to what we want. m:Community Wishlist is one of them. It's probably a bit more involved than what we want, but should have some technical bits we could reuse.

Another way could be having a separate subpage for each report. Then put them together in a table on the main page. This would probably need a Lua module, but shouldn't be to hard. This would likely make it a bit trickier to just add manually or edit.

I have been thinking of two solutions:

1. Having two separate pages:

• One page where the user can report errors
• One page to summarize

2. Have everything in Extension:Wikispeech/Pronunciation_errors

1st section:
Having a form similar to Community_Wishlist

2nd section:
The summary of all submitted reports in a similar table as we have today (i.e Extension:Wikispeech/Pronunciation_errors/sv)

In T395320#10909262, @Viktoria_Hillerud_WMSE wrote:

I have been thinking of two solutions:

1. Having two separate pages:

• One page where the user can report errors
• One page to summarize

2. Have everything in Extension:Wikispeech/Pronunciation_errors

1st section:
Having a form similar to Community_Wishlist

2nd section:
The summary of all submitted reports in a similar table as we have today (i.e Extension:Wikispeech/Pronunciation_errors/sv)

I think option 2. is a better choice, I'll go with that for now.

Since it seems not possible to add a form on a page, if it isn't a special page, I need to think more about how to fix this, and what could be a good solution

Change #1163302 had a related patch set uploaded (by Viktoria Hillerud WMSE; author: Viktoria Hillerud WMSE):

[mediawiki/extensions/Wikispeech@master] Make it easier to report pronunciation errors

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

Having looked at the code and not tested yet I have a couple of questions:

1. This requires you to have something selected. If not you just get an error message. Is this intentional? I think you should still be able to report an error in that case. You'd just need to enter the word manually.
2. There's no validation of the selection. You can selected multiple words or only part of one for instance. I think it would be better to check against tokens in utterances. You should be able to reuse logic from the selection player or the highlighter for this. You probably also want the selected text to be in an editable field.
3. Did you try building context using the utterance of the selected word? Again the logic in the highlighter should be usable here.

Everything is done in the frontend. Did you look at what could be done in the backend instead? This would offload the users device. It may be tricky to do with the gadget solution. Perhaps it's worth weighing pros and cons of having the feedback page on the producer wiki instead of under the extension page.

In T395320#11156931, @Sebastian_Berlin-WMSE wrote:

Having looked at the code and not tested yet I have a couple of questions:

1. This requires you to have something selected. If not you just get an error message. Is this intentional? I think you should still be able to report an error in that case. You'd just need to enter the word manually.
2. There's no validation of the selection. You can selected multiple words or only part of one for instance. I think it would be better to check against tokens in utterances. You should be able to reuse logic from the selection player or the highlighter for this. You probably also want the selected text to be in an editable field.
3. Did you try building context using the utterance of the selected word? Again the logic in the highlighter should be usable here.

In T395320#11206051, @Sebastian_Berlin-WMSE wrote:

Everything is done in the frontend. Did you look at what could be done in the backend instead? This would offload the users device. It may be tricky to do with the gadget solution. Perhaps it's worth weighing pros and cons of having the feedback page on the producer wiki instead of under the extension page.

I’m a bit unsure where I should focus my efforts next, since your two latest comments point in somewhat different directions:

• Your first comment focused on improving the UX and frontend functionality
• The second one raised a more backend question

Is the idea to explore both directions in parallel, or would you prefer I focus on one before the other?

Let me know what you think makes most sense as a next step!

I didn't mean that you should remove the frontend entirely. I still think that is useful to make it easy to use.

There is some logic that could live in the backend to offload the users device. For instance there's a request that sends the entire page content. You could instead have request that takes a small number of parameters (word, language, page etc.) and have the backend deal with adding it to the correct place. This would be a new API action.

Another thing to consider is how to do it when you only have one wiki. Even though what we have in production at the moment (and for the foreseeable future) uses producer and consumer wikis, the primary way to use Wikispeech should arguably be on a single wiki. If it proves too much work to cover that now we could to stick with supporting what we run now. In that case you should make sure that you don't build something that will be difficult to adapt to a single wiki.

Now I have implemented a bit better on the frontend part, even though I can see the logic may a bit messy regarding validation of the selected word through tokens and utterances, but I couldn't figure out how to do in in another way. Feel free to comment on this code on gerrit.

I have not started on the backend part of this task though, but I will investigate what you proposed regarding maybe creating a new API-action, and by creating a new API-action I would have to create a ned API-module right?

Yes, a new action would mean a new API module.

As for now, the new Api-module doesn't include consumerUrl.. Probably want that

Now it should include logic for consumer-url.

How do you trigger this? When I click the feedback button I'm just redirected to the page Extension:Wikispeech/Pronunciation_errors/ (on the local wiki).

There is no point in "making it easier to report pronunciation errors" as the bottle neck seems to be the handling of already reported errors. ;-)

I am still waiting for a response and frequent status reporting on the planned actions for the pronunciation errors that I reported between June and August 2021, i.e. four years ago, on the page https://www.mediawiki.org/wiki/Extension:Wikispeech/Pronunciation_errors/sv
See also:

• https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen/Arkiv_2021-06#Testa_Wikispeech
• https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen/Arkiv_2021-10#Uppdatering_av_Wikispeech-test
• https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Larske/Testsida11

In T395320#11364961, @Larske wrote:

There is no point in "making it easier to report pronunciation errors" as the bottle neck seems to be the handling of already reported errors. ;-)

I am still waiting for a response and frequent status reporting on the planned actions for the pronunciation errors that I reported between June and August 2021, i.e. four years ago, on the page https://www.mediawiki.org/wiki/Extension:Wikispeech/Pronunciation_errors/sv
See also:

• https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen/Arkiv_2021-06#Testa_Wikispeech
• https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen/Arkiv_2021-10#Uppdatering_av_Wikispeech-test
• https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Larske/Testsida11

Hi! The reason we’re working on improving the reporting process is precisely because the current way of handling pronunciation errors has proven inefficient.
By creating a better structure for collecting and managing reports, we aim to make it easier to address issues more effectively over time.

Wikispeech is still under development, and we’re doing our best with the resources available.
That said, you’re absolutely right that we can and should improve how we communicate progress and updates, especially in places like the discussions and pages you linked. We’ll take that on board going forward!

Appreciate your continued engagement!

It looks like this only works on the wiki where Wikispeech is installed. That's good as the default, but the way we have it set up now we'd want to use a page on an external wiki. Is that something you plan for this task or will that be a follow up?

In T395320#11373428, @Sebastian_Berlin-WMSE wrote:

It looks like this only works on the wiki where Wikispeech is installed. That's good as the default, but the way we have it set up now we'd want to use a page on an external wiki. Is that something you plan for this task or will that be a follow up?

Yes exactly! I was planning on having that as a follow up, since we don't really have that external wiki yet

In T395320#11373429, @Viktoria_Hillerud_WMSE wrote:

[...] we don't really have that external wiki yet

Weren't we going to stick with https://www.mediawiki.org/wiki/Extension:Wikispeech/Pronunciation_errors?

In T395320#11373445, @Sebastian_Berlin-WMSE wrote:

In T395320#11373429, @Viktoria_Hillerud_WMSE wrote:

[...] we don't really have that external wiki yet

Weren't we going to stick with https://www.mediawiki.org/wiki/Extension:Wikispeech/Pronunciation_errors?

Hmm.. yes, but it would need some refactoring. But you meant how to link to that page in the code I understand now.
So this is what you meant in config variable in extension.json?

Yes. When you specify the error page it could be either a local one or one on another wiki. In case of the former you'd use the logic you have in the patch. In the latter you'd use the other wikis API.

Of course it's best to keep as much code as possible common. I'd imagine that all the logic for creating the wikitext should be the same for example.

I see, then it sounds best if I fix all of this in this patch

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.

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.

When I tried from a consumer it doesn't work. Looks like it's trying to make the request to the local wiki instead of the producer. I haven't looked too closely at the code yet. Would you say that it's reasonable to use the new API on the producer wiki or would it be better to implement it in the frontend as you started with? Even if there are advantages with the former we also need to take into account how complex it makes the code.

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.

Yes exactly, I must have forgot to tell you that this must be done in order for it to work, and I think it is a good idea to in the future automate it, but for now make instructions for it in some way.

When I tried from a consumer it doesn't work. Looks like it's trying to make the request to the local wiki instead of the producer. I haven't looked too closely at the code yet. Would you say that it's reasonable to use the new API on the producer wiki or would it be better to implement it in the frontend as you started with? Even if there are advantages with the former we also need to take into account how complex it makes the code.

A question regarding this, how do you try from consumer? What settings do you make to test it?

And regarding the new API-solution: I think using the API on the producer makes sense, even if it could be complex.
The previous frontend-only flow (e.g. editing the report page manually) isn’t used anymore. The current UI submits via the API directly.

Finally I understood the complexity 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.

This led me to realize that the request was being made using mw.Api(), which always only targets the local wiki. The correct approach is to use mw.ForeignApi() when the producer is located on a different domain.
After updating the implementation to use ForeignApi(), and setting $wgWikispeechProducerMode = true; I confirmed that the reporting functionality now works as expected!

Next steps: I’ll explore whether Wikispeech’s existing RemoteWikiPageProvider can be reused to handle remote edits. Most likely, I’ll need to extend it with support for editing pages (e.g. fetching CSRF tokens, posting updates), since it currently only supports reading. Do you think this is a good idea? @Sebastian_Berlin-WMSE
Right now, this logic is inside ApiWikispeechReportPronunciation:saveToExternalWiki()

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

Instead, I’m keeping the editing logic (token fetching, editing etc) within ApiWikispeechReportPronunciation::saveToExternalWiki(), where it’s directly related to the API's purpose, reporting pronunciation errors.

I think that this separation keeps RemoteWikiPageProvider focused only on reading remote pages

I disagree.

I think having a class that handles communication with a remote wiki makes sense. It's possible that we want to do this more in the future.

We should also try to avoid putting logic into the APIs that isn't strictly for the APIs (e.g. reading parameters and formatting output). We recently broke out logic from the listen API because it was needed elsewhere. If for instance we decide that we want make a maintenance script that does some cleaning up on error page we'd have to do that again here.

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.

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.

I still plan to refactor insertRowIntoReportTable and saveToExternalWiki into RemoteWikiPageProvider, but I need the config reading to work first.

Any ideas what could be wrong or what to try next? @Sebastian_Berlin-WMSE

What does the code look like where you use the config variable? What does getConfig()->get() return?

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 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 that size alone doesn't disqualify from having a separate class. If the logic is distinct enough it can be worth it even if there are only a few functions. This makes improves the structure. It's also possible that we want to expand it at some point and if we wait until it's Big Enough™ it'll probably be more work figuring out what bits should go where.

(Having worked on the frontend in T182289 I have fresh experience of how confusing it can be with unclear separation. And that's code that I've probably written most of myself 🙈)